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1.  INTRODUCTION 


Fach  day  at  the  various  federal  departments  hundreds  of  peo- 
ple a s k.  or  are  asked  questions  similar  to  the  following: 

* Are  certain  types  o t crime  related  to  unemployment 
figures? 

* What  agencies  are  managing  programs  relating  to 
income  transfer? 

* Will  the  data  obtained  from  the  LANDSAT  satellite 
program  justify  the  cost? 

* Do  increases  in  the  the  school  lunch  program  lead 
to  increased  achievement  by  the  students  who  parti- 
cipate in  the  program? 

* How  much  of  the  oil  consumed  in  the  United  States 
is  produced  from  domestic  sources? 

The  ability  to  answer  questions  such  as  these  determines,  to  a 
large  deqree,  the  success  of  a governmental  department.  Yet,  the 
answers  do  not  come  easily.  Part  of  the  reason  lies  in  the  type 
of  problems  which  the  public  has  begun  to  expect  its  government 
to  solve.  In  a world  where  societies  have  Become  increasingly 
interdependent,  the  solutions  to  problems  have  become  progres- 
sively more  difficult.  Yet,  the  government  has  found  that  it 
cannot  afford  to  increase  without  bound  the  number  of  people,  the 
amount  of  dollars,  and  the  quantity  of  equipment  that  it  employs 
to  solve  society's  problems  or  even  to  obtain  the  answers  to 
questions  such  as  those  iisted  above.  In  personnel,  for  example, 
comparing  the  number  of  people  in  the  Federal  work  force  to  the 
number  of  people  in  the  overall  work  force  produces  figures  which 
have  remained  relatively  stable  over  the  past  30  years.  The  per- 
centage of  Federal  workers  in  the  total  work  force  was  3%  in 
1947,  4%  in  1964,  3%  in  1974  and  3%  in  1976  11J.  Consequently, 

departments  have  not  been  getting  real  increases  in  the  numbers 
of  people  which  are  sufficient  to  offset  the  growing  volume  of 
work  resulting  from  increased  responsibilities.  One  manifesta- 
tion of  this  is  an  increasing  workload  which  has  resulted  in 
rapidly  growing  amounts  of  data  that  must  be  processed  and  turned 
into  information  for  the  department's  consumers.  In  producing 
information  products,  a department  employs  a vast  storehouse  of 
disparate  knowledge  concerning  tactual  events,  analytic  tech- 
niques, and  o r gani za t i onal  goals.  An  understanding  of  and 
improvement  in  this  process  is  the  subject  of  this  paper. 

Tr ad i t iona 1 1 y the  governmental  departments  have  turned  to 
electronic  computers  for  help  in  attempting  to  cope  with  their 
flood  of  work,  and  the  computer  has  responded  by  demonstrating  a 
prodigious  capacity  for  processing  data.  That  this  data  process- 
ing has  oeen  a "help"  is,  perhaps,  debatable  when  one  considers 
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the  massive  increase  in  the  number  of  government  forms  which  are 
currently  needed  to  feed  this  new  "assistant."  The  countless 
side  feet  of  paper  output,  the  growing  number  of  arbitrary 
retrieval  languages,  and  the  almost  total  incompatibility  of  data 
on  different  machines  are  other  manifestations  of  some  of  the 
difficulties  which  have  come  along  with  the  widespread  introduc- 
tion of  this  technology.  Moreover,  orders  of  magnitude  reduc- 
tions in  the  cost  of  computing  and  storage  have  accelerated  the 
pace  of  tne  introduction  of  electronic  data  processing  Dy  allow- 
ing tne  aovernment  to  purchase  more  computing  power  and  storage 
for  the  same  dollars.  Yet  with  each  acquisition  the  question 
remains  the  same:  "Is  the  government  really  increasing  the  pro- 
ductivity of  its  departments  by  such  acquisitions?"  Will  the  peo- 
ple in  the  Department  of  Transportation,  for  example,  have  more 
skill,  expertise,  or  knowledge  in  transpor tation  systems  because 
of  their  use  of  computers?  The  ability  to  collect,  massage,  and 
store  data  nas  greatly  improved  over  the  last  decade,  but  many 
departments  seem  to  be  acquiring  far  more  data  than  they  can 
intelligently  use.  The  logistics  of  keeping  track  of  what  data 
they  have  on  which  topics  is  overpowering  and  threatens  to  get 
worse  as  more  and  bigger  systems  are  installed  at  the  various 
departments.  Computer  networks  (e.g.,  ARPANET , 1NF0NET,  EFTS, 
the  defunct  EEDNET)  are  now  possible  which  can  link  together  many 
large-scale  systems.  Keeping  track  of  which  systems  do  what  and 
what  data  is  stored  where  will  become  a major  technological  issue 
in  the  very  near  future.  The  purpose  of  this  paper  is  twofold: 
Cl)  to  address  what  can  be  done  to  enable  a department  to  keep  up 
witn  an  ever-increasing  volume  of  data,  and  (2)  to  propose  a 
future  which  emphasizes  providing  new  generations  of  tools  to 
improve  the  quantity  and  quality  of  information  which  a depart- 
ment can  produce.  This  paper  will  show  how  computer  technology 
can  oe  used  to  formalize,  analyze,  extend,  and  preserve  many  of 
the  skills,  expertise,  and  knowledge  which  are  so  important  to 
any  Federal  Department. 

Organizations  in  industry  and  government  have  begun  to  recog- 
nize some  of  the  symptoms  of  their  computer-related  problems. 
Some  of  these  organizations  have  chosen  to  view  data  as  a cor- 
porate resource  [2,3,4,5,6,71.  An  outgrowth  of  these  endeavors 
nas  been  tne  development  of  tne  concept  of  an  "enterprise."  For 
tne  Purposes  of  this  report  an  enterprise  is  defined  to  be  any 
total  organization  (e.g.,  a government  agency,  a large  corpora- 
tion, or  a small  company)  which  commonly  pools  its  resources  in 
order  to  achieve  some  collective  goals.  More  and  more,  manage- 
ment in  these  oraanizat ions  is  beginning  to  enforce  constraints 
on  tne  subdivisions  of  their  enterprise  which,  prior  to  the 
instigation  of  the  data-as-a-r esource  philosophy,  were  thought  to 
"own"  the  data  oases  of  the  organization  individually.  At  the 
same  time,  these  enterprises  have  been  expending  increasing 
amounts  of  time  and  money  in  an  effort  to  ma«e  their  data,  espe- 
cially computerized  data,  generally  available  to  all  of  their 
members.  In  many  organizations  where  data  has  been  recognized  as 
a valuable  resource  of  the  enterprise  on  a par  with  personnel, 
money,  material,  and  facilities,  the  need  has  surfaced  to  manage 
this  resource  actively  and  effectively  from  a global  or 
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enterprise  point  ot  view.  Needs  sucn  as  these  have  led  to  the 
recent  rapid  growth  in  the  establishment  of  corporate  data  bases 
and  tne  use  ot  associated  software  (data  base  management  sys- 
tems). Many  Federal  departments  are  presently  in  such  a growth 
stage  as  is  evidenced  by  tne  increased  use  ot  and  interest  in 
data  case  management  systems  by  a large  number  ot  organizations. 
These  needs  have  also  led  to  an  introduction  of  shared  data  net- 
works as  mentioned  above.  Network  technology  is  generally  becom- 
ing accepted  as  a reasonable  way  for  an  enterprise  to  insure  that 
the  valuable  data  resource  will  be  available  equitably  to  all  of 
its  subdivisions.  In  tnis  paper  we  suggest  that  the  real 
resource  which  a department  should  be  seeking  to  understand  and 
extend  is  not  just  its  data  but  its  knowledge.  Extending  the 
data-as-a-resource  philosophy  to  the  concept  of  knowledge-as-a- 
resource  can  be  a complicated  process,  but  one  which  we  feel  can 
yield  real  benefits  to  a department.  In  this  paper  we  introduce 
this  new  concept  and  outline  some  steps  which  can  be  taken  to  use 
tnis  resource  effectively. 

Acceptance  of  the  concept  of  treatinq  knowledge  as  a 
resource,  of  course,  will  not  oe  automatic.  Organizations  are 
loatn  to  change  tne  manner  in  which  they  operate,  and  it  gen- 
erally requires  a confrontation  with  several  major  problems 
before  sucn  a philosophy  will  even  be  considered.  We  suggest 
that  the  following  set  ot  problems  have  either  reached  a critical 
state  in  many  departments  or  will  soon  become  pressing  enough  to 
command  widespread  attention  and  will,  therefore,  set  off  a 
search  for  solutions.  Many  solutions  may  be  found  in  the  philo- 
sophy of  treating  knowledge  as  a resource. 

1.1  PROBLEMS 

Several  crucial  problems  are  appearing  as  the  government 
moves  from  the  world  of  stand-alone  data  processing  to  the  world 
of  interconnected  computer  networks.  These  problems  include 
increasing  costs,  individual  privacy,  lack  ot  security,  freedom 
of  information  requirements,  data  sharing,  multiple  user  inter- 
faces, inadequate  problem-solving  support,  and  the  loss  of 
governmental  expertise.  Tnese  problems  have  been  compounded  by 
tne  lack  ot  a unifying  philosophy  which  could  have  been  used  as 
tne  oasis  for  ar chi tectural  planning  and  systems  development. 
These  problems  are  just  mentioned  briefly  here.  They  will  be 
discussed  in  greater  detail  at  the  appropriate  time  in  the  paper. 

1.1.1  COSTS 

As  indicated  in  the  preceding  section,  the  trend  in  the  vari- 
ous departments  over  the  past  few  years  has  seen  increasing  pres- 
sure to  produce  more  ana  better  information  with  the  same  or 
fewer  (but  more  expensive)  people.  During  this  period,  the  cost 
of  computer  storage  and  hardware  has  continued  on  a steady 
decline  so  that  departments  are  able  to  buy  more  and  more  com- 
puter power  with  constant  dollars.  In  many  instances,  this 
increased  computer  power  is  being  distributed  closer  to  the  indi- 
vidual government  workers  and  away  from  large  centralized 
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computer  complexes.  There  has  been  a very  real  shift  in  total 
systems  cost  away  from  the  hardware  and  toward  the  software  and 
user-time  spent  in  accessing  the  computer  systems.  The  problem 
now  is  how  can  an  organization  place  guantitative  values  on  the 
cost  of  humans  versus  machines  and  how  can  they  evaluate  the 
trade-offs  i ntel l igent ly . Furthermore,  the  introduction  of  com- 
puter networks  will  make  available  to  users  a large  amount  of 
(cheap)  computing  power  and  a huge  amount  of  data.  The  organiza- 
tion and  effective  management  of  this  dispersed  computing  power 
will,  itself,  present  significant  problems. 

1.1.2  PRIVACY 

Privacy  is  an  issue  which  has  received  considerable  attention 
in  recent  years  and  will  continue  to  grow  in  importance  in  the 
years  ahead.  Dr.  Willis  Ware  of  the  Rand  Corporation  described 
the  basic  privacy  issues  thusly:  "An  individual  has  given  per- 
sonal information  to  a record-keeping  system  in  exchange  for  some 
right,  privilege,  benefit,  or  opportunity...  The  individual,  in 
his  action  to  provide  personal  information,  does  so  with  the 
expectation  that  it  will  De  used  for  the  purpose  for  which  he 
gave  it.  It  is  nis  implicit  expectation  that  such  information 
will  oe  used  in  his  best  interest  and  certainly  not  in  any  way  to 
his  detriment.  He  does  not  expect  to  be  annoyed,  pressured, 
harassed,  or  harmed  by  its  use."  18] 

An  individual's  right  to  privacy  was  brought  to  the  attention 
of  government  departments  with  the  passage  of  the  Privacy  Act  of 
1974  [9J.  This  act  instructs  departments  to  maintain  their 
record-keeping  systems  in  a manner  which  will  result  in  accuracy, 
relevance,  timeliness,  and  completeness.  It  specifies  that  indi- 
viduals may  bring  civil  actions  against  Federal  agencies  for  any 
damages  which  might  occur  as  a result  of  actions  which  violate  an 
individual's  rights  which  are  protected  under  the  law.  It  also 
provides  for  personal  penalties  for  officers  and  employees  who 
willfully  reveal  material  whose  disclosure  was  prohibited  by  the 
act.  Since  almost  all  governmental  record-keeping  systems  are 
covered  py  this  act,  departments  are  discovering  that  they  need 
to  construct  their  record-keeping  systems  in  a manner  which  meets 
the  requirements  of  the  law. 

1.1.3  SECURITY/INTEGRITY 

Dr.  Ware  (8)  has  defined  security  as:  "(a)  the  protection  of 
a computer  system  per  se  and  the  information  within  it  against 
accidental  or  deliberate  damage,  (b)  providing  such  information 
onLy  to  authorized  users,  and  (c)  doing  so  on  a timely  basis." 
Security  has  been  an  issue  of  concern  to  some  government  people 
for  a long  time,  especially  those  who  handle  classified  informa- 
tion. However,  the  passage  of  the  Privacy  Act  of  1974  mandated 
tnat  all  the  various  agencies  begin  to  consider  the  security  of 
their  record-keeping  systems  to  guarantee  the  privacy  of  the 
individuals  involved.  The  act  states  that  "Lach  agency  ...  shall 
...  establish  appropriate  administrative,  technical,  and  physical 
safeguards  to  insure  the  security  and  confidentiality  of  records 
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and  to  protect  against  any  anticipated  threats  or  hazards  to 
their  security  or  integrity  which  would  result  in  substantial 
narm,  embarrassment,  inconvenience,  or  unfairness  to  any  indivi- 
dual on  whom  information  is  maintained"  19] . These  security 
requirements  are  much  stronger  tnan  those  which  may  have  been 
required  in  the  past.  Satisfying  these  requirements  will  neces- 
sitate substantial  technical  improvements  in  the  way  (.computer- 
ized) data  is  guarded. 

1.1.4  FREEDOM  OF  INFORMATION 

The  objective  of  the  Freedom  of  Information  Act  (F01)  of 
196b  is  to  encourage  and  mandate  the  sharing  of  data,  informa- 
tion, and  Knowledge  oetween  the  government  and  its  citizens. 
This  act  gives  all  persons  a judicially  enforceable  right  to  see 
all  records  of  Federal  agencies  except  to  the  extent  that  the 
records  may  be  covered  by  an  "exemption."  The  requester  need 
give  no  reason  for  the  request.  Thus,  some  of  the  objectives  of 
the  Fill  may  De  in  conflict  with  the  objectives  put  forth  in  the 
Privacy  Act.  In  seeKing  to  sort  out  how  these  conflicts  are  to 
oe  resolved,  a Code  of  Fair  Information  Practices  [10]  has  been 
drawn  up.  The  Code  states  that: 

* Protection  should  be  limited  to  data  identifiable 
witn  or  traceaole  to  specific  individuals. 

* Protection  should  be  specific  enough  to  qualify  for 
nondisclosure  exemption  under  tne  Freedom  of  Infor- 
mation Act. 

* Protection  should  be  available  for  data  in  the  cus- 
tody of  all  statistical  reporting  ana  research  sys- 
tems whether  supported  by  Federal  funds  or  not. 

* Federal  law  snould  oe  controlling;  no  state  statute 
should  interfere  witn  the  protection  provided. 

* Either  the  custodian  or  the  individual  about  whom 
tne  data  is  sougnt  should  be  able  to  invoke  the 
protection,  but  only  the  individual  should  be  able 
to  waive  it. 

The  result  is  that  Federal  Departments  are  faced  with  rather  dif- 
ficult decisions  concerning  the  data,  information,  and  Knowledge 
wnicn  they  might  wish  to  place  into  their  record-keeping  systems. 

1.1.5  DATA  SHARING 

The  proolems  of  access  and  sharing  among  various  computers 
witn  tneir  individual  data  representations  and  data  storage  tech- 
ni  jues  cannot  De  solved  cy  technology  alone.  Privacy,  security, 
integrity,  and  freedom  of  information  rights  also  must  be  con- 
sidered. in  addition,  a deeper  understanding  of  the  structure 
and  meaning  of  records  and  data  bases  is  required  before  stored 
data  can  oe  shared  effectively  by  many  different  individuals. 
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However,  the  autonomous  nature  of  the  various  government  discip- 
lines guarantees  tnat  individual  pockets  of  data  will  remain 
almost  unintelligible  to  persons  who  are  not  steeped  in  the  lore 
of  the  discipline  of  the  government  analysts  who  "own"  the  data. 
There  Is  a need  to  develop  mechanisms  which  will  enable  people  to 
use  the  government  data  (which  is  available  under  the  FUI). 
These  mechanisms  should  require  minimal  amounts  of  cross-training 
in  multiple  joo  skills.  In  addition,  the  difficulties  of  knowing 
what  data  is  available  ana  then  of  locating  and  using  it  in  a 
computer  network  are  already  well-known  to  network  users  and  will 
become  widely  known  as  computer  networks  spread.  The  problem 
will  become  even  more  acute  when  citizens  attempt  to  obtain  data 
from  the  government,  we  believe  that  the  data  access  and  sharing 
problems  just  now  surfacing  will  become  even  more  significant  as 
tne  government  places  more  reliance  on  computerized  systems  in 
the  years  ahead. 

1.1.6  MULT1PLIC  I ry  OF  USER  INTERFACES 

Tne  proolem  of  a multiplicity  of  interface  types  (e.g.,  pro- 
grams, retrieval  languages,  or  forms)  and  a multiplicity  of  kinds 
within  each  type  (e.g.,  multiple  retrieval  languages)  has  already 
surfaced  among  computer  populations  (witness  the  ARPANET  or  the 
collection  of  terminals  which  confront  the  users  of  INFONET,  for 
example).  Such  multiplicity,  while  useful,  requires  extensive 
training  of  government  employees  and  private  citizens  in  areas 
extraneous  to  their  primary  disciplines.  In  addition,  these 
interfaces  are  often  unnatural  to  their  human  users  and  they  pro- 
vide a limited  view  of  the  data  (i.e.,  a view  forced  upon  the 
human  oy  the  computer  which  is  being  used  to  manage  the  data).  A 
more  human-or iented  approach  to  user  interfaces  is  needed. 

1.1.7  INADEQUATE  PROBLEM-SOLVING  SUPPORT 

I’oday ' s computerized  analytical  tools  are  frustratingly 
inflexiole  and  provide  almost  no  support  for  the  less  algorithmic 
problem-solving  activities  of  government  personnel  (i.e., 
analysis).  Statistical  subroutines,  for  example,  often  are  use- 
ful only  tor  a specific  type  or  format  of  data.  Documentation  on 
their  use  is  all  too  often  inadequate.  Such  tools  in  their 
present  form  are  almost  impossible  to  share  and  result  in  costly 
duplication  of  effort.  More  flexible  tools  which  support  analyt- 
ical processes  are  requireo. 

1.1.8  LOSS  OF  EXPERTISE 

The  services  of  many  of  tne  government's  most  renowned 
experts  in  the  various  disciplines  such  as  health,  transporta- 
tion, or  agriculture  continually  are  being  lost  because  of 
retirement  or  resignation.  Indeed,  when  those  experts  leave  the 
Federal  service  they  take  with  them  10,  20,  or  perhaps  30  years 
of  orecious  knowledge  obtained  through  their  experiences  in  par- 
ticular applications  areas.  Evidence  that  the  current  means  of 
retaining  and  transferring  their  expertise  is  inadequate  is  mani- 
fested as  the  same  mistakes  are  repeated  over  and  over  again 
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during  subsequent  attempts  to  obtain  solutions  to  recurring  prob- 
lems. (This  is  not  to  discount  the  worth  of  new  approaches  to 
old  problems  by  new  employees#  but  rather  to  supply  them  with 
sufficient  information  about  what  has  been  tried  before.)  An 
integral  part  of  this  problem  is  the  methodology  for  preserving 
the  unique  skills  found  in  the  various  departments.  We  presently 
attempt  to  preserve  skills  through  publications#  professional 
courses,  textbooks,  and  on-the-job  training.  Each  of  these 
approaches,  however,  is  labor-intensive  and  not  an  integral  part 
of  a department's  mission.  Instead,  they  are  generally  regarded 
as  overhead  functions  which  will  be  performed  "when  someone  gets 
around  to  it."  A more  effective  way  of  preserving  the  technical 
knowledge  which  analysts  and  experts  possess  is  desperately 
needed. 

1.1. 9 NO  UNIFYING  INFORMATION  SYSTEM  PHILOSOPHY 

No  unifying  pnilosophy  seems  to  exist  which  can  be  used  as 
the  oasis  for  an  overall  information  systems  architecture  to  sup- 
port knowledge  production  and  use.  For  the  most  part,  analytic 
disciplines  in  the  various  departments  are  autonomous  (a  result, 
pernaps,  of  intensive  professionalization  programs)  and  this  is 
reflected  in  the  difficulty  that  arises  when  trying  to  communi- 
cate across  disciplines.  In  addition,  projects  and  programs  are 
tnemselves  largely  autonomous  with  not  much  attention  being  paid 
to  other  projects  in  designing  new  systems  (a  result,  perhaps,  of 
project  management  orientation).  Finally,  tnere  is  the  continu- 
ing problem  of  imprecise  requirements  which  reflect  the  natural 
uncertainty  which  is  indigenous  to  the  types  of  problems  under 
the  purview  of  government.  In  too  many  cases,  by  the  time  a com- 
puterized information  system  has  been  developed  to  support  a 
given  area  or  program,  it  no  longer  meets  the  requirement  oecause 
the  circumstances  for  its  use  or  the  laws  dictating  its  use  have 
changed.  Unfortunately,  computerized  systems  are  many  times  too 
inflexible  to  accommodate  the  necessary  changes  and  continue  to 
survive,  forcing  humans  to  change  to  meet  the  system's  demands. 
The  problem  is  compounded  when  such  systems  interface  with  the 
public. 

1.2  KNOWLEDGE  RESOURCE  SOLUTION 

As  our  nation  moves  into  increasingly  more  difficult  times, 
the  quality,  quantity,  and  availability  of  knowledge  in  the  pub- 
lic sector  will  become  more  important.  Yet,  we  must  move  cau- 
tiously in  these  areas  because  tightly  held  knowledge  often  has 
served  as  a significant  source  of  power  tor  the  government 
bureaucracy,  and  actions  wnich  would  tend  to  result  in  further 
increases  in  bureaucratic  power  are  not  desirable.  However,  such 
problems  are  not  new  and  many  great  thinkers  in  our  nation  have 
put  forth  solutions.  The  quote  from  James  Madison  which  precedes 
tnis  paper  suggests  one  such  solution.  We  believe  that  Madison 
was  advocating  power  sharing  through  knowledge  sharing  and  we 
also  oelieve  that  knowledge  sharing  can  best  be  achieved  through 
the  creation  of  departmental  "knowledge  resources."  Furthermore, 
we  feel  that  a "knowledge  resource"  as  we  define  it  below  will 
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promote  solutions  to  many  ot  tne  problems  identified  above. 

For  proof  that  tne  issues  of  knowledge  and  its  use  are 
timely  and  relevant,  one  only  need  turn  to  the  current  public 
administration  literature  where  the  relationships  between 
knowledge,  society,  and  the  bureaucracy  have  been  examined  under 
the  topic  of  "knowledge  management"  [11]  . In  our  view,  and  for 
the  purposes  of  this  paper,  the  term  knowledge  management  has  a 
more  limited  and  technically-oriented  meaning,  namely  the  process 
wnereoy  knowledge  (as  defined  in  Section  2)  is  acquired,  main- 
tained, transferred,  and  preserved  as  a basic  resource  of  an 
enterprise.  However,  even  in  this  limited  context  the  term 
knowledge  management  must  not  be  taken  to  imply  control  and  mani- 
pulation ot  public  knowledge  nor  should  it  suggest  that  we  might 
oe  proposing  that  the  government  Increase  its  power  over  its 
citizens  by  "managing  all  human  knowledge,"  We  do  not  advocate 
either  position  and  therefore,  we  shall  concentrate  on  the  proper 
management  ot  the  existing  knowledge  resource  ot  an  enterprise, 
it  is  our  nope  that  the  creation  of  an  organizational  knowledge 
resource  will  help  to  promote  widespread  knowledge  sharing  within 
governmental  departments  and  also  between  the  departments  and  the 
citizens  whom  they  serve. 

Establishing  a knowledge  resource  will  require  a set  ot  con- 
cepts which  are  meant  to  promote  the  understanding,  use,  and 
sharing  ot  the  Knowledge  which  is  already  found  in  a given 
Federal  department  or  agency.  To  be  meaningful,  the  concept  of  a 
knowledge  resource  requires  a theory  of  knowledge  (which  we 
present  in  Section  2)  to  provide  a vocabulary  and  framework  for 
addressing  the  subject.  To  be  useful,  a knowledge  resource 
requires  a model  upon  which  an  organization  can  build 
people/ machine  systems  to  improve  the  processes  of  acquiring, 
handling,  using,  sharing,  and  preserving  the  knowledge  which  is 
essential  to  tne  operation  of  that  organization.  We  discuss  such 
a model  in  Section  8.  The  basic  idea  behind  a knowledge 
resource,  tnen,  is  tnat  the  knowledge  (including  the  data  and  the 
procedures  which  are  employed  to  manipulate  that  data)  which  is 
found  in  government  departments  is  understandable  and  definable. 
Furthermore,  it  is  cohesive  enough  to  allow  a department  to  con- 
struct systems  capable  of  improving  the  organization's  produc- 
tion, use,  and  sharing  of  knowledge.  We  contend  that  the  expli- 
cit recognition  ot  knowledge  as  an  organizational  resource  can 
have  a large  impact  on  the  design  and  construction  of  computer- 
ized systems  which  might  be  used  to  assist  in  the  processing  of 
an  organization's  knowledge.  However,  progress  will  not  come 
easily  and  considerable  work  in  many  different  areas  will  be 
required  before  effective  knowledge  resources  can  be  built  by  the 
various  F'ederai  departments.  In  the  sections  that  follow  we 
attempt  to: 

(1)  develop  a foundation  tor  the  concepts  of  a 

knowledge  resource  (Sections  2 and  3), 

(2)  relate  how  government  activities  could  use  a 

knowledge  resource  (Section  4), 
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( 1)  define  the  roles  of  various  pieces  of  existing 
technology  (Sections  5 and  6), 

(4)  suggest  some  steps  which  a department  can  take  to 
oegin  to  Duild  an  effective  knowledge  resource 
(Sections  7,  8 , and  9),  and 

( b ) indicate  particular  areas  which  will  require  addi- 
tional research  (Appendix  1). 

Our  set  of  knowledge  resource  concepts,  we  feel,  can  begin  to 
provide  solutions  to  the  problems  of  cost,  privacy,  security, 
integrity,  freedom  of  information  needs,  data  sharing,  inadequate 
user  interfaces,  inadequate  problem-solving  support,  and  loss  of 
expertise.  Finally,  we  expect  that  the  concepts  which  will  be 
needed  to  create  a knowledge  resource  will  be  able  to  provide  the 
foundation  upon  which  a unifying  systems  architecture  can  be 
developed. 

The  discussion  contained  in  this  report  is  primarily  aimed  at 
the  F’ederal  Government.  inis  orientation  is  due,  in  large  part, 
to  the  background  of  the  authors  and  their  familiarity  with 
government  problems.  The  application  of  the  ideas  contained 
nerein  to  areas  other  than  those  mentioned  in  the  body  of  this 
report  will,  at  least  for  the  present,  be  left  to  the  reader. 
F'or  those  wnose  orientation  and  thinking  are  more  toward  the  cor- 
porate or  business  side,  we  recommend  an  earlier  paper  entitled 
"Managing  Knowledge  as  a Corporate  Resource"  [12]  which  discusses 
some  of  these  issues. 
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2.  KNOWLEDGE  TAXONOMY 

If  a department  is  to  conceive  of  Knowledge  as  an  organiza- 
tional resource,  it  must  nave  some  means  of  understanding  and 
classifying  the  various  types  of  Knowledge  whicn  it  employs  in 
fulfilling  its  departmental  role.  The  totality  of  an 
organization's  Knowledge  has  many  aspects  and  means  different 
things  to  different  people.  Consequently,  it  is  a confusing  sub- 
ject which  does  not,  in  most  current  organizational  environments, 
seem  to  have  sufficient  cohesion  to  allow  the  organization  as  a 
whole  to  discuss  the  components  of  a "Knowledge  resource."  In 
order  to  till  the  need  for  a high-level  view  of  Knowledge  which 
has  a cor  responding  set  of  basic  terminology  to  describe  that 
view,  we  have  developed  a generalized  taxonomy  of  Knowledge  which 
we  believe  can  be  used  to  understand  the  Knowledge  which  is  found 
in  any  governmental  department.  we  do  not  propose  that  this  tax- 
onomy encompasses  all  forms  of  human  Knowledge.  Rather,  it  is 
limited  to  the  Knowledge  which  is  most  relevant  to  the  function- 
ing of  a government  department  or  agency.  At  the  same  time,  the 
taxonomy  is  not  to  be  construed  as  being  limited  only  to 
Knowledge  whicn  might  today  Cor  in  the  future)  be  found  in  compu- 
terized systems  (although  computers  will  undoubtedly  play  a large 
part  in  storing  and  manipulating  such  Knowledge). 

For  our  purposes.  Knowledge  includes  what  a department  Knows 
Ci.e.,  information),  what  It  Knows  how  to  do  (i.e.,  techniques), 
and  what  it  Knows  about  why  it  does  what  it  does  (i.e.,  wisdom). 
Figure  2-1  shows  a classification  of  these  types  of  Knowledge 
into  three  areas:  Factual  Knowledge,  Procedural  Knowledge,  and 
Judgmental  Knowledge.  Factual  Knowledge  deals  with  the  facts  or 
data  about  the  world  which  are  of  interest  to  the  department. 
Procedural  Knowledge  concerns  the  operations  or  procedures  which 
are  applied  to  other  Knowledge  in  order  to  organize  it  better  or 
to  transform  it  into  new  Knowledge.  Judgmental  Knowledge 
Involves  the  morals,  values,  and  ethics,  the  rules  and  regula- 
tions, and  the  goals  and  objectives  to  which  the  people  in  a 
department  subscribe  and  which  influence  their  behavior.  Each 
person  in  a department,  from  clerK  to  chief,  employs  all  three 
types  of  Knowledge  in  conducting  his  or  her  daily  business.  Many 
times  the  distinction  as  to  which  type  of  Knowledge  is  being  used 
in  a given  instance  is  not  clear  because: 

(1)  a fair  amount  of  the  Knowledge  in  an  organization 
is  hidden  (being  contained  solely  within  human 
heads  and  never  written  down); 

(2)  there  are  hierarchies  of  Knowledge  contained  within 
eacn  category  (tactual,  procedural,  and  judgmen- 
tal); 

(3)  eacn  type  of  Knowledge  may  employ  other  types  as 
input  (tor  example,  a statistical  routine  needs  to 
have  some  data  as  input); 


Knowledge  Taxonomy 


Page  11 


C 4 ) judgmental  Knowledge,  since  it  involves  morals, 
values,  ethics,  and  tne  interpretation  of  rules  and 
regulations,  can  be  somewhat  nebulous; 

(5)  people  are  not  used  to  sorting  out  types  of 
Knowledge;  and 

(b)  Knowledge  has  different  contexts. 

This  latter  point  suggests  that  our  classification  of 
Knowledge  into  general  forms  or  types  could  be  be  improved  by 
considering  the  subject  matter  (or  context)  to  which  the 
Knowledge  pertains.  This  expansion  is  discussed  in  Section  3.2. 
The  primary  advantage  of  recognizing  various  contexts  is  the  con- 
ceptual separation  of  subject  matter  according  to  the  needs  and 
purposes  of  the  individual  maKing  use  of  the  Knowledge.  An 
understanding  that  Knowledge  has  different  contexts  is  crucial  to 
the  development  of  computer  systems  which  are  meant  to  assist  in 
the  building  and  the  use  of  a Knowledge  resource.  Developers  of 
computerized  information  systems  in  the  past  apparently  have 
failed  to  recognize  the  differences  which  are  pointed  out  in  the 
taxonomy,  and  as  a result,  the  systems  generally  have  not  been 
responsive  to  the  Knowledge  requirements  of  the  users.  We  con- 
tend that  consideration  of  the  taxonomy  in  Figure  2-1  and  the 
contexts  in  Figure  3-1  can  be  useful  in  pointing  out  the  differ- 
ences among  the  various  types  and  contexts  of  Knowledge  and  the 
need  to  Keep  them  as  separate  as  possible  when  developing  com- 
puter systems  (a  situation  which  we  term  "Knowledge  independence" 
- see  Section  3.1). 
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2.1  FACTUAL  KNUWLEDGE 

Factual  Knowledge  comprises  the  "What"  component  of  a 
department's  aggregate  Knowledge,  It  deals  with  specific  facts 
("data")  and  the  relationsnips  ("metadata")  which  the  department 
cnooses  to  consider  important  among  the  various  data  items.  The 
data,  tnerefore,  reflects  someone's  perception  of  reality  while 
the  metadata  provides  a frame  of  reference  which  can  be  used  to 
interpret  tne  facts  or  the  data.  The  presence  of  botn  components 
is  necessary  it  a tactual  Knowledge  base  is  to  be  widely  useful 
to  tne  organization.  The  importance  of  this  statement  will  be 
made  clearer  in  the  following  paragraphs. 

2.1.1  DATA  (FACTS) 

"data"  is  defined  to  be  recorded  symbols  of  all  types.  This 
oroad  definition  of  data  is  meant  to  include  all  of  the  recorded 
symools  of  the  or ganizati on , including  its  reports,  correspon- 
dence, forms,  charts,  pictures,  etc.  It  also  includes  the  sym- 
ools which  are  recorded  on  the  storage  media  of  the  department's 
computers.  These  latter  items  are  considered  to  be  part  of  a 
department's  computerized  "data  banKs." 

Most  computerized  data  banKs  consist  mainly  of  collections  of 
stored  values.  For  example,  a data  banK  may  contain  instances  of 
line  voltages  which  are  associated  with-  various  pieces  of  electr- 
ical equipment  used  by  tne  organization.  The  stored  values  of 
these  instances  comprise  the  data.  However,  the  data  values,  of 
themselves,  are  not  very  useful  because  they  generally  are  not 
meaningful  except  to  the  people  who  were  responsible  for  storing 
tnem  in  tne  first  place.  (Access  to  numbers  such  as  "120", 
" 240 " , "6 " , " 1 2 " , "10",  "9.3",  etc.  is  not  very  meaningful.) 
Furthermore,  it  is  Decoming  clear  that  storing  more  and  more  data 
values  whose  meaning  is  Known  to  only  a few  people  is  not  a 
satisfactory  situation  because  there  also  must  be  some  (implied) 
linx  oetween  things  wnich  exist  in  the  real  world  ahd  the  data 
values  whicn  many  individuals  have  recorded  in  the  data  banKs  of 
their  organization.  Merely  recording  the  data  value  "120",  for 
example,  is  of  little  worth  unless  it  relates  to  some  activity  in 
wnicn  tne  organization  is  interested.  Even  then,  this  raw  value 
is  very  amoiquous  to  most  people  in  the  organization  since  it  is 
impossible  for  most  of  tnem  to  tell  to  what  the  numoers  refer. 
To  overcome  this  ambiguity,  it  is  useful  to  associate  the  value 
"120"  with  another  object  (an  attribute)  called  "volts."  An 
"attribute"  is  defined  to  oe  some  property  which  is  common  to  all 
of  the  objects  wnich  are  in  a given  class.  Today,  such  associa- 
tion is  done  mainly  in  people's  heads  where  it  is  not  accessible 
to  otner  numans.  In  any  case,  the  pairing  "volts/120",  is  called 
an  "attr ibute/value  pair."  Such  pairing  is  the  first  step  toward 
reducing  the  ambiguity  of  the  values  in  the  data  base.  Ambiguity 
still  exists,  tnough,  because  the  pairing  does  not  indicate  which 
objects  in  the  real-world  can  have  the  attribute  (property)  of 
"volts"  nor  wnich  could  have  tne  value  of  "120".  However,  the 
creation  of  an  at t r ibute/ va lue  pair  of  "volts/120"  has  already 
served  to  limit  the  context  of  the  value,  "120"  to  some 
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measurement  ot  voltage.  Tnus  the  attribute/value  pair 
"volts/120"  should  be  related  to  one  or  more  objects  which  use 
voltage  ( i.e.,  typewriters,  calculators,  air  conditioners,  ter- 
minals, computers,  etc.).  If  someone  in  the  organization  needs 
to  set  up  a floor  plan  which  is  to  specify  where  the  different 
objects  are  to  be  placed,  then  this  person  must  understand  which 
associations  ( ob jects /attr ibutes/ values ) are  correct  for  each  of 
the  objects.  It  the  records  on  these  objects  were  placed  in  data 
banks  which  contain  only  values,  then  access  to  the  data  banks 
will  not  provide  sufficient  knowledge  about  the  meaning  of  the 
data.  The  pairing  ot  the  objects  and  attributes  with  the  correct 
values  would  have  to  be  provided  by  a person  who  understands  the 
data  in  the  data  bank.  Factual  knowledge  which  is  constructed  in 
this  fashion  ties  organizational  ability  to  take  an  action  (draw- 
ing up  a floor  plan)  to  an  ability  to  contact  the  person  who 
holds  tne  missing  Pieces  of  the  needed  knowleage.  This  type  of 
situation  can  be  very  harmful  to  an  organization  if  the  right 
people  aren't  available  at  tne  right  times.  In  the  following 
paragraphs  we  shall  examine  how  an  organization  can  construct  its 
tactual  knowledge  oases  in  ways  which  can  minimize  unnecessary 
dependence . 

Continuing  with  the  example  in  the  preceding  paragraph,  "com- 
puters" were  identified  as  one  of  the  objects  which  could  have  an 
attribute  ot  "voltage"  and  someone  might  have  stored  "240"  in  a 
data  bank  as  the  value  ot  the  voltage  requirement  of  a particular 
computer.  "Computer,"  in  this  case,  is  said  to  be  a real-world 
entity  about  which  the  enterprise  (i.e.,  the  department)  desires 
to  record  attribute/value  pairs  of  "volts/240."  An  "entity"  is 
defined  to  oe  a person,  place,  thing,  or  event  that  exists  in 
some  portion  ot  tne  real-world  which  is  of  interest  to  the  enter- 
prise. in  order  to  define  what  constitutes  a qiven  entity,  it  is 
useful  to  associate  certain  attributes  with  each  entity.  In  the 
previous  example,  the  entity  "computer"  might  be  assigned  the 
attributes  ot  "model  number",  "serial  number",  "size",  "voltage", 
"line  frequency",  etc.  In  data  processing  terminology  the  total 
collection  of  attributes  and  values  which  are  associated  with  a 
single  object  miqht  be  known  as  a "record"  and  each  attribute 
known  as  a "field."  (Unfortunately,  the  data  processing  meanings 
tor  "records"  and  "fields"  are  not  restricted  to  objects  and 
attributes  since  "records"  and  "fields"  also  may  consist  ot  arbi- 
trary mixtures  of  different  objects,  attributes,  and  values.)  An 
enterprise  which  has  chosen  to  organize  its  factual  knowledge 
along  tne  lines  of  entities,  attributes,  and  values  has  taken  a 
first  step  toward  creating  a foundation  upon  which  the  factual 
portion  of  a knowledge  resource  can  be  implemented. 

I’nere  are  important  conceptual  differences  between  conven- 
tional data  processing  notions  (which  form  the  basis  for  most  of 
today's  data  banks)  ana  the  ideas  of  entities,  attributes,  and 
values.  These  differences  become  crucial  if  an  organization 
decides  to  begin  to  build  a knowledge  resource.  They  also  become 
important  it  one  believes  that  one  of  the  main  functions  of  a 
knowledge  resource  is  to  facilitate  knowledge  sharing. 
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Organizational  adoption  of  the  concept  of  entities,  attri- 
butes, and  values  allows  the  organization  to  define  data  about 
data,  i.e,,  metadata  (see  2.1.2  below).  Metadata  can  be  used  to 
form  conceptual  models  which  can  represent  the  real-world  which 
is  relevant  to  the  organization.  This  enables  humans  to  work 
with  the  conceptual  models  which  are  supplied  by  the  metadata 
portion  of  tactual  Knowledge  without  needing  to  get  involved  in 
tne  voluminous  number  of  instances  which  might  occur  in  a data 
bank.  The  provision  for  high-level  access  to  conceptual  mooels 
also  plays  a major  role  in  more  advanced  problem-solving  activi- 
ties (see  Section  2.2.2)  since  the  metadata  can  be  useful  in 
directing  more  in-depth  searches,  i.e.,  in  pruning  irrelevant 
data.  For  example,  providing  metadata  on  the  entity  "food  pro- 
duction" allows  an  analyst  to  begin  to  understand  this  entity  in 
an  abstract  way  without  having  to  examine  the  entire  data  bank. 
Frequently,  many  questions  can  be  answered  at  this  high  level 
(and  can,  in  tact,  be  handled  more  efficiently).  Thus,  answers 
to  a query  such  as  "Do  we  have  any  facts  on  food  production  in 
Asia/"  can  be  obtained  by  accessing  the  metadata  bases  alone 
without  accessing  the  actual  (facts)  data  banks.  Of  course, 
obtaining  specific  tactual  data  such  as  "How  much  rice  was  pro- 
duced in  Indonesia  in  1975?"  would  necessitate  accessing  the  tac- 
tual data  banks.  (Even  so,  the  metadata  can  be  used  to  select 
only  those  data  banks  which  are  likely  to  contain  relevant 
facts . ) 

2.1.2  METADATA  ( PEL AT  I ON SH 1 PS ) 

A useful  capability  to  nave  when  dealing  with  entities  is  an 
ability  to  group  objects  together  into  a set  and  to  refer  to  this 
grouping  in  a named  aggregate.  For  example,  when  entities  of  the 
same  object  class  have  some  of  tne  same  properties,  then  they  can 
be  grouped  into  an  aggregate  called  an  "entity  set"  (sometimes 
called  "tiles"  in  data  processing  terms).  The  collection  of  all 
computers  owned  oy  the  organization  is  one  example  of  an  entity 
set.  Tne  collection  of  all  computers  leased  by  the  organization 
is  another  entity  set.  The  collection  of  all  departmental  equip- 
ment is  the  "equipment  inventory"  entity  set,  and  so  forth.  The 
ability  to  define  hierarchies  of  entities  through  the  set  concept 
is  very  powerful  and  will  allow  an  organization  to  build  complex 
entity  sets  wnlch  reflect  the  complexities  of  the  real  world. 

Quite  often  it  is  desirable  for  an  enterprise  to  be  able  to 
define  relationships  between  different  entities  or  sets  of  enti- 
ties wnlch  reflect  their  natural  association  in  the  real-world 
(at  least  the  natural  associations  as  viewed  by  the  enterprise). 
These  relationships  can  provide  a frame  of  reference  which  could 
oe  used  to  supply  meaning  to  the  data.  In  the  example  mentioned 
above,  it  may  be  useful  tor  a department  to  Identify  a relation- 
ship oetween  food  production  and  exports  and  imports  of  food. 
Furtnermore,  it  might  be  useful  to  specify  a relationship  between 
food  production  and  the  strains  of  plants  used  in  the  production. 
There  mlgnt  be  other  relationships  between  the  areas  wnere  food 
is  produce!  and  the  plants  which  are  grown.  Relationships  can 
begin  to  get  more  obscure,  tor  example,  when  attempts  are  made  to 
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relate  oil  imports  and  food  production  Coil  can  be  converted  into 
fertilizer).  Metadata,  then,  is  defined  to  be  tne  aggregate  of 
tne  entity  sets  and  the  relat ionsnips  which  exist  among  the  vari- 
ous entitles  and  entity  sets.  It  also  describes  the  structure  of 
an  entity  set  as  well  as  tne  format  of  the  entities  themselves. 
To  a large  degree,  metadata  is  what  gives  a factual  knowledge 
case  its  potential  tor  meaning  (based  on  the  conceptual  model 
which  it  represents).  In  the  realm  of  data  base  management  one 
generally  speaks  of  a combination  of  data  and  metadata  as  a "data 
base"  while  a collection  of  plain  facts  or  data  is  often  termed  a 
"data  bank."  we  find  this  a useful  distinction  and  we  shall 
attempt  to  adhere  to  it  throughout  the  remainder  of  this  paper. 


2,1.3  INFORMATION 

Factual  knowledge,  then,  is  the  term  used  to  describe  the 
entities,  attributes,  values,  entity  sets,  and  relationships 
which  are  associated  with  the  real-world  objects  represented  in 
the  ’'data  base.  All  of  these  things  will  need  to  be  in  a data 
base  which  is  to  be  part  of  a knowledge  resource.  It  is  far  too 
easy,  however,  to  create  a data  bank  (not  a data  base)  which  is 
useful  to  only  a very  limited  number  of  individuals. 

The  reason  that  data,  alone,  is  not  very  useful  is  because  it 
is  almost  devoid  of.  meaning  except  to  the  person  who  recorded  it. 
Recording  a fact  about  a strain  of  rice,  for  example,  may  be 
meaningful  only  to  a particular  agronomist.  If  the  facts  are  to 
nave  wide  utility  to  other  people  besides  this  agronomist  then 
these  people  must  be  provided  more  knowledge  before  they  will 
find  this  fact  to  be  useful.  They  will  need  access  to  the  set  of 
relationships  which  the  agronomist  believed  to  be  relevant  to  the 
rice  entity.  The  degree  to  which  the  agronomist  is  able  to  pro- 
vide metadata  will  determine  how  widely  his  factual  knowledge  can 
be  snared. 

Factual  knowledge,  even  if  it  is  constructed  in  the  manner 
which  we  suggest,  often  has  a limited  life-span  and  it  can  lose 
its  utility  with  the  passage  of  time.  (The  concept  of  time  with 
respect  to  data  bases  is  a complex  issue  which  will  be  discussed 
later  in  paragraph  2.6).  For  example,  mixes  of  crops  in  food 
production  might  change,  exports  may  turn  into  imports,  strains 
of  plants  may  be  wiped  out  by  disease,  etc.  These  time-related 
changes  need  to  oe  noted  and  the  new  relationships  recorded. 

For  many  years,  departments  have  been  processing  data  and 
creating  data  banks.  with  the  recent  advent  of  data  base  manage- 
ment systems,  some  of  them  have  begun  to  process  factual 
knowledge  and  they  have  begun  to  construct  metadata  and  to  create 
data  bases.  However,  the  creation  and  use  of  metadata  is  still 
in  its  infancy  and  organizations  have  much  to  learn  in  this  area. 
All  of  this  activity,  especially  the  move  toward  the  use  of  data 
base  management  systems,  might  be  regarded  as  steps  in  tne  right 
direction.  However,  departments  can  still  do  much  to  improve  the 
processing  of  procedural  and  judgmental  knowledge  as  well. 
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2.2  PROCEDURAL  KNOWLEDGE 

Procedural  knowledge  concerns  the  "How"  component  ot  a 
department's  aggregate  knowledge.  It  includes  their  operations, 
procedures,  and  problem-solving  technigues.  In  effect,  pro- 
cedural knowledge  is  what  the  enterprise  knows  how  to  do. 

In  order  to  classify  this  type  of  knowledge  we  have  found  it 
helpful  to  employ  a continuum  of  knowledge  which  was  developed  by 
Herbert  Simon  in  I960  113J.  The  extremes  of  Simon's  continuum 
are  labeled  programmed  and  nonprogrammed.  In  Figure  2-2  we  show 
this  continuum.  We  nave  elected  to  use  the  terms  "algorithmic" 
and  "heuristic"  to  refer  to  Simon's  concepts  of  programmed  and 
nonprogrammed  knowledge  to  avoid  confusion  in  terminology  since 
we  wisn  to  use  the  words  "program",  "programming",  and  "pro- 
grammed" in  their  conventional  computer  context. 

Algorithmic  procedural  knowledge  is  used  for  repetitive  and 
routine  problems  which  can  be  solved  by  detailed  step-by-step 
procedures.  Examples  include  such  things  as  statistical 
routines,  measurement  routines,  instructions  for  using  conversion 
taDles,  and  some  scientific  formulas.  Heuristic  procedural 
knowledge,  on  the  other  hand,  Includes  the  procedures  which  are 
used  to  solve  unstructured  problems.  Technigues  tor  inferencing, 
heuristic  search  strategies,  and  reasoning  (see  Section  2.2.2) 
are  examples  ot  heuristic  procedural  knowledge.  Generally,  it  is 
not  too  difficult  to  distinguish  between  algorithmic  and  heuris- 
tic knowledge,  but,  as  with  all  continua,  items  which  fall  near 
the  middle  frequently  will  have  character  1st  lcs  of  both  classifi- 
cations, and  tne  sharp  distinctions  tend  to  become  blurred.  The 
two  categories  ot  procedural  knowledge  are  explained  in  greater 
detail  below. 
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2.2.1  ALGORITHMIC  PROCEDURAL  KNOWLEDGE  (Programmed) 

Algorithmic  procedural  Knowleage  is  used  whenever  problems 
are  stereotyped  and  routine  and  are  amenable  to  being  solved  by 
tne  repetitive  application  of  some  step-by-step  rules  or  pro- 
cedures. Use  of  this  Knowledge  implies  a complete  and  detailed 
understanding  of  the  problem  and  its  solution.  Algorithmic 
Knowledge  frequently  can  be  expressed  in  a computer  program  where 
tne  programmer  is  able  to  specify  carefully  tne  passing  of  con- 
trol from  one  piece  of  program  code  to  another.  Every  instruc- 
tion to  tne  computer  must  be  understood  and  carefully  placed  in 
tne  proper  sequence.  Federal  Departments,  by  and  large,  nave 
been  very  successful  in  computerizing  algorithmic  Knowledge  and, 
to  a large  aegree,  most  of  tne  computer  power  in  the  various 
departments  is  devoted  to  this  type  of  activity.  For  example, 
most  of  tne  computing  capacity  found  in  the  Social  Security 
Administration  is  devoted  to  preparing  checKs  and  maintaining 
records  (algorithmic  activities). 

Unfortunately,  not  all  of  a department's  problems  can  be 
solved  algor ithmlcally.  Analysts  employ  heuristics  or  "rules- 
of-tnumo"  which  they  have  ouilt  up  over  a number  of  years  of 
experience  in  their  analytic  discipline  in  order  to  solve  certain 
problems,  to  determine  which  algorithms  are  relevant,  or  to  con- 
struct new  algorithms  as  warranted.  For  example,  the  process  of 
determining  the  eligibility  for  the  social  security  checKs  men- 
tioned above  would  generally  be  classed  as  a heuristic  process. 

2.2.2  HEURISTIC  PROCEDURAL  KNOWLEDGE  ( Nonpr ogrammed ) 

Heuristic  procedural  Knowledge  is  used  to  solve  problems  or 
to  react  to  situations  when  it  is  not  possible  to  prespecify  a 
particular  algorithmic  solution.  Heuristic  Knowledge  is  gen- 
erally specific  to  sKill  areas  such  as  economics,  medicine, 
mathematics,  etc.  but  it  can  also  involve  general  common  sense 
reasoning  as  well.  Specific  heuristic  Knowledge  is  used  to  guide 
solutions  or  reactions  and  it  is  frequently  expressed  in  either 
goal-driven  or  data-driven  terms.  A transportation  planner  who 
seeKs  to  obtain  the  "best"  mix  for  the  expenditure  of  public 
transportation  dollars  (tne  goal)  is  operating  with  goal-driven 
heuristic  Knowledge.  An  economist  who  is  running  various  sta- 
tistical tests  (algorithmic  Knowledge)  on  census  results  (the 
data)  is  operating  with  a data-driven  set  of  heuristics.  The 
results  of  each  test  might  suggest  certain  paths  to  pursue  and 
close  otner  paths  from  further  consideration.  In  this  latter 
example,  the  results  of  the  execution  are  used  in  a heuristic 
fashion  to  determine  what  is  to  be  done  next. 

Another  common  form  of  heuristic  procedural  Knowledge  is 
inferencing.  There  are  three  types  of  inferencing  whicn  are  gen- 
erally recognized:  deductive,  inductive,  and  abductive  (14). 
Deductive  inference  refers  to  the  process  of  reasoning  that  what- 
ever is  true  of  all  instances  or  members  of  a class  must  oe  true 
of  one  instance  or  member.  Tne  premise  of  the  deductive  argument 
is  said  to  provide  definite  evidence  tor  its  conclusion.  This 
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point  is,  at  the  same  time,  its  strength  and  its  weakness.  If  a 
deduction  does  not  nave  a major  premise  which  is  without  excep- 
tion true,  then  attempts  to  use  this  form  of  logic  will  not  have 
the  expected  inevitability. 

Inductive  inference  is  a form  of  reasoning  where  a body  of 
facts  or  observations  are  used  to  discover  rules  or  generaliza- 
tions which,  more  or  less,  explain  the  observed  phenomena. 
Stated  another  way,  induction  means  to  generalize  from  a number 
of  cases  of  which  something  is  true,  and  inter  that  the  same 
thing  is  probably  true  of  a whole  class.  This  type  of  inferenc- 
ing  is  directly  related  to  reasoning  by  analogy  and  it  has  much 
in  common  with  statistical  probability  theory.  An  example  of 
inductive  inference  would  oe  for  a doctor  to  examine  the  * records 
of  all  of  his  polio  patients,  to  observe  that  all  had  had  high 
fevers  in  the  early  stages  of  the  disease,  and  then  to  generalize 
a rule  which  stated  that  one  of  the  probable  characteristics  of 
polio  is  the  occurrence  of  a high  fever  in  the  patient.  If, 
unfortunately,  the  doctor  were  also  to  observe  that  all  of  the 
polio  patients  were  homeowners,  then  he  or  she  might  conclude 
that  the  state  of  being  a homeowner  was  also  a characteristic  of 
having  polio.  What  this  points  up  is  the  fact  that  the  premise 
may  or  may  not  provide  definitive  evidence  for  the  conclusion. 

Abductive  inference  is  a kind  of  reasoning  where  a 
nypotnesis  is  formed  which,  if  true,  would  explain  some  collec- 
tion of  observed  facts.  For  example,  an  observation  that  Jane 
Smitn  has  spots  when  taken  with  the  rule  that  all  people  who  have 
measles  also  have  spots  might  leaa  a doctor  to  hypothesize,  via 
abductive  inference,  that  perhaps  Jane  has  measles.  The  problem 
with  arriving  at  a definite  conclusion  at  this  point  is  the  tact 
that  other  types  of  disease  might  also  produce  spots.  Therefore, 
a necessary  step  in  this  form  of  inference  Is  to  attempt  to  iden- 
tify additional  evidence  which  could  be  used  to  support  the 
hypothesis.  A high  fever  and  a coated  tongue  also  might  be 
characteristics  which  sometimes  are  present  in  people  who  have 
measles  (and  many  other  diseases  as  well).  Positive  or  negative 
indications  of  symptoms,  if  taken  in  combination  through  the  pro- 
cess of  abductive  inference,  may  lend  strong  support  to  a given 
nypothes  i s . 

as  a further  illustration  of  what  is  meant  by  heuristic  pro- 
cedural knowledge,  consider  the  following  example  of  a very  sim- 
ple type  of  problem:  solving  a jigsaw  puzzle  which  has  1,000 
pieces.  A brute  force  algorithmic  solution  would  involve  1,000 
factorial  trials  and  the  sneer  size  of  this  number  dictates  that 
this  algorithmic  approach  is  not  practical.  Therefore,  most  peo- 
pLe  do  not  attempt  to  solve  such  a problem  with  a brute  force 
approach.  Instead,  they  might  begin  to  analyze  the  problem  in 
order  to  identify  any  characteristics  which  might  be  exploitable 
for  solution.  The  results  of  such  exploration  might  reveal  that 
it  is  possible  to  construct  stable  partial  solutions  to  the  prob- 
lem (parts  of  the  puzzle  can  be  assembled  and  then  used  later  to 
ouild  bigger  parts).  In  addition,  there  seem  to  be  two  distinct 
types  of  data  which  will  oe  available  during  the  puzzle-solving 
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activity:  the  snape  ot  the  contours  and  the  designs  printed  on 
the  surfaces.  Therefore,  the  problem-solver  might  hypothesize 
that  it  would  be  possible  to  place  all  of  the  pieces  of  a partic- 
ular color  in  one  or  more  piles  or  to  place  all  of  the  edge 
Pieces  ih  another  pile.  These  observations  and  hypotheses  are 
used  by  the  problem-solver  to  formulate  a problem-solving  stra- 
tegy which  consists  of  formulating  the  problem  in  a way  in  which 
stable  subcohstr uct ions  can  be  formed  and  built  upon.  (This 
means  to  choose  sections  of  the  puzzle  which  would  appear  to  be 
easier  to  put  together.)  Another  part  of  the  strategy  is  to 
characterize  the  rules  of  construction  along  two  or  more  dimen- 
sions (color  and  shape)  which  are  not  perfectly  correlated  but 
which  are  each  sufficient  (generally)  to  determine  the  correct 
solution.  As  a person  proceeds  toward  the  solution,  different 
f acts  about  the  puzzle  become  evident  at  various  points  in  the 
solution  process.  The  circumstances  may  be  such  that  the  data  is 
incomplete,  subjective,  or  erroneous  (a  situation  which  is  quite 
prevalent  in  many  real-life  problems).  For  example,  a aog  may 
nave  chewed  off  the  corners  of  some  of  the  pieces  or  may  have 
destroyed  some  ot  the  images.  Thus,  at  any  point  in  time,  a 
person's  data  concerning  the  problem  or  its  solution  may  be 
incomplete.  Nevertheless,  the  objective  is  to  continue  toward  the 
solution  by  using  the  subconstructions  as  they  are  built.  These 
subconstructions  can  be  used  as  feedback  to  help  the  puzzle- 
solver  understand  the  entire  puzzle  before  it  is  constructed. 
This  helps  speed  the  solution  along.  Thus,  while  it  may  not  be 
possible  to  define  a total  algorithmic  solution  to  puzzle  solv- 
ing, it  is  relatively  easy  to  define  a set  of  heuristics  which 
are  quite  useful  in  such  activity. 

As  illustrated  in  the  above  examples,  heuristic  knowledge  is 
extremely  flexible  and  is  capable  of  dealing  with  a broad  variety 
of  problems  and  situations.  it  is  the  most  common  form  of 
Knowledge  used  by  government  analysts  but  very  little,  if  any,  of 
this  Knowledge  is  presently  computerized.  Instead,  it  remains 
the  purview  of  tecnnical  specialists  who  have  received  extensive 
training  in  such  problem-solving  areas. 

2.3  JUDGMENTAL  KNOWLEDGE 

Judgmental  Knowledge  includes  the  "Why"  component  of  a 
department's  aggregate  knowledge.  It  deals  with  the  wisdom  which 
is  used  to  determine  which  factual  and  procedural  knowledge  is 
relevant  to  a given  decision.  The  exercise  ot  judgmental 
Knowledge  (especially  in  tne  public  sector)  also  includes  con- 
sideration of  moral  and  legal  issues  before  making  a decision, 
we  oelieve  that  there  are  two  types  of  judgmental  knowledge:  (1) 
Constraints  (which  include  Values  and  Regulations)  and  (2)  Goals 
(which  include  Objectives). 

2.3.1  CONSTRAINTS  (VALUES  AND  REGULATIONS) 

Values  are  a form  ot  knowledge  which  are  obtained  from 
society  and  experience.  Generally,  values  consist  of  the  written 
and  unwritten  guidelines  to  moral  ano  ethical  conduct  which  are 
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expected  of  employees  of  tne  enterprise.  The  Federal  Employees' 
Code  of  Ethics,  the  Code  of  Ethics  tor  the  Association  for  Com- 
puting Machinery  (ACM),  and  the  Ten  Commandments  are  examples  of 
values  that  have  been  written  down.  Rules  of  social  behavior  or 
conditions  for  survival  are  examples  of  values  which  are, 
perhaps,  less  formalized.  Values  do  not  carry  the  force  of  law 
and  cannot  be  used  as  a legal  defense  to  Justify  a decision. 

Regulations  are  a form  of  Knowledge  similar  to  values  but 
which  are  written  down  in  the  form  of  statutes  or  rules  of  con- 
duct which  carry  the  force  of  law  and  judicial  action.  The 
privacy  Act  and  the  Freedom  of  Information  Act  are  two  well-Known 
examples  of  sucn  statutes.  The  Civil  Service  Regulations  are 
examples  of  government-wide  rules  which  are  meant  to  guide  and 
control  employee  conduct  at  all  agencies. 

The  importance  of  the  need  to  include  moral  and  legal  con- 
siderations in  the  dec ision-maKing  process  has  been  underlined  by 
recent  events  involving  all  branches  of  government  which  have 
revealed  guestionaole  ethical  or  legal  conduct.  Therefore,  we 
must  emphasize  that  a department  needs  to  provide  for  the  appli- 
cation of  judgmental  Knowledge  in  its  use  of  a Knowledge 
resource.  Uur  logical  system  design  which  is  discussed  in  Sec- 
tion B provides  a place  where  humans  can  exercise  judgmental 
Knowledge . 

2.1 .2  GOALS  AND  OBJECTIVES 

Goals  are  a form  of  Knowledge  which  defines  the  basic  mission 
of  a given  department.  They  are  often  given  in  broad  terms.  For 
example,  the  Economic  Research  Service  (ERS)  of  the  U.s.  Depart- 
ment of  Agriculture  has  the  broad  goal  of  developing  and  provid- 
ing economic  information  to  members  of  Congress,  USDA  policy 
officials,  other  government  agencies,  State  and  local  officials, 
foreign  government  leaders,  farmers,  farm  organizations,  marKet- 
ing  firms,  and  farm  supply  companies. 

Broad  goals  are  often  broKen  down  into  more  specific  goals 
which  are  intended  to  further  refine  the  definition  of  the 
organization's  mission.  Specific  goals  which  relate  to  the  mis- 
sion of  the  ERS,  for  example,  include  developing  economic  infor- 
mation on: 

♦ U.s.  food  and  fiber  production 

♦ farm  and  rural  adjustments 

♦ agricultural  use  of  natural  resources 

♦ consumer  interests  relating  to  agriculture 

♦ foreign  trade  of  agriculture  products 

♦ USDA  international  technical  assistance 

rne  goals  specified  above  may  be  further  refined  at  increas- 
ing levels  of  detail  in  oraer  to  clarify  the  definition  of  the 
organization's  mission.  If  properly  done,  the  goals  and  subgoals 
should  form  a tree  which  can  be  traced  from  top  to  bottom.  Oth- 
erwise, it  will  be  difficult  for  a department  (or  anyone  else  for 
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that  matter)  to  understand  why  it  engages  in  the  activities  that 
it  does. 

Objectives  relate  to  the  specific  actions  or  tasks  which  are 
to  oe  completed  in  connection  with  particular  goals.  Essen- 
tially, objectives  should  serve  as  a means  to  measure  the  pro- 
gress toward  some  goal  or  set  of  goals.  When  used  this  way,  the 
objectives  generated  by  the  organization  are  frequently  spelled 
out  in  Management-by-Objective  programs  or  they  may  be  expressed 
as  milestones  in  project  management  charts. 

A specific  objective  which  is  designed  to  satisfy  the  goal  of 
making  economic  information  more  available  might  be  to  provide 
"Supply  and  Demand  Estimates"  on-line  in  a computer  network  which 
would  be  readily  available  to  a wide  variety  of  government  and 
non-government  users.  An  objective  which  is  meant  to  satisfy  a 
goal  of  providing  more  timely  information  might  involve  changing 
tne  update  cycle  of  figures  on  "Agricultural  Statistics"  from  a 
yearly  oasis  to  a quarterly  basis. 

Goals  and  objectives  can  be  externally  or  internally  gen- 
erated, External  goals  might  be  provided  by  Congress  when  they 
pass  legislation.  Laws  often  define  the  areas  which  the  legisla- 
tors expect  will  be  addressed  by  their  legislation  and  they  also 
may  specify  performance  criteria  which  are  expected  to  be  met. 
Such  external  definitions  and  criteria  might  be  directly 
translatable  into  internal  organizational  goals  and  objectives. 

The  area  of  judgmental  knowledge  is  the  most  ill-defined  and 
least  understood  aspect  of  the  knowledge  which  exists  in  an 
organization.  Nevertheless,  there  is  a need  to  support  the  human 
exercise  of  judgmental  knowledge  as  it  relates  to  the  knowledge 
resource  of  an  organization . Judgmental  knowledge  should  be  used 
to  justify  the  collection,  use,  sharing  and  retention  of  the 
other  forms  of  knowledge.  If  some  set  of  facts  does  not  relate 
to  the  basic  mission  of  the  organization,  then  they  should  not  De 
collected  or  retained.  Great  masses  of  personal  data  on  indivi- 
duals are  available  but  this  does  not  mean  that  a department 
should  decide  to  try  to  collect  them.  Judgmental  knowledge 
(rules,  regulations,  laws,  ethics)  should  be  used  to  determine 
whether  such  an  activity  should  be  allowed  to  take  place. 

Portions  of  what  we  define  as  judgmental  knowledge  may  never 
be  placed  into  any  computerized  system.  Nevertheless,  the  abil- 
ity to  apply  all  forms  of  judgmental  knowledge  is  important  and 
failure  by  an  organization  to  recognize  the  need  for  such  con- 
sideration can  lead  to  the  design  of  systems  and,  ultimately,  to 
tne  creation  of  a knowledge  resource  which  is  not  adequate  to 
meet  organizational  needs. 

2.4  KNOWLEDGE  ABSTRACTION 

Knowledge,  in  general,  includes  concepts  which  are  abstracted 
from  other  knowledge  over  a relatively  long  period  of  time.  It 
is  these  processes  of  abstraction  which  occupy  most  of  an 
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organi zation ' s time  and  energy.  Organizations  are  seldom 
interested  in  understanding  or  explaining  all  of  the  complexities 
of  the  phenomena  which  exist  in  the  real-world.  Instead,  they 
desire  to  understand  only  that  portion  which  is  relevant  to  them. 
LucKily,  Knowledge  is  amenable  to  a "top-down"  approach  and  a 
Knowledge  resource  can  be  built  in  this  fashion.  Most  of  what  is 
Known  in  science,  for  example,  was  constructed  in  just  this 
fashion.  There  was  a great  deal  of  Knowledge  on  physical  and 
cnemical  behavior  before  there  were  molecular  chemistry  theories 
and  they,  in  turn,  preceded  atomic  theory. 

The  process  of  abstraction  is  important  to  our  concepts  of  a 
Knowledge  resource  to  reduce  the  amount  of  understanding  which 
nuinans  will  neea  to  possess  in  order  to  use  the  Knowledge  in  the 
resource.  In  tne  example  from  the  preceding  paragraph,  it  is 
possible  to  use  molecular  chemistry  theory  without  being  an 
expert  in  atomic  tneory.  The  necessary  abstractions  only  need 
provide  an  approximate,  simplified  characterization  of  atomic 
tneory  which  is  at  a lower  level  of  Knowledge  than  molecular 
chemistry  which  is,  itself,  lower  in  a Knowledge  hierarchy  than 
theories  of  cnemical  behavior.  The  characteristics  of  hierar- 
chies of  abstractions,  and  hierarchies  of  Knowledge  itself,  are 
capable  of  being  exploited  when  they  are  organized  into  a 
Knowledge  resource. 

Abstractions  also  nave  another  character i st ic  which  is  useful 
when  building  a Knowledge  resource.  They  are  capable  of  convey- 
ing succinctly  substantial  amounts  of  information  (witness:  any 
formula  In  mecnanical  pnysics)  without  reguiring  the  explicit 
enumeration  of  all  possible  instances  of  the  data.  This  charac- 
teristic aids  understanding  and  promotes  Knowledge  sharing  since 
it  is  possible  to  provide  a lot  of  Knowledge  with  a very  small 
amount  of  data. 

Aostractions  are  useful  in  still  another  sense.  They  permit 
an  organization  to  characterize  the  objects  in  their  data  bases 
in  such  a way  that  it  is  possible  to  focus  on  a few  characteris- 
tics which  might  be  of  general  interest  to  the  entire  organiza- 
tion. For  example,  it  is  possible  to  abstract  out  the  tensile 
and  compressive  strengths  of  many  materials  (woods,  metals,  plas- 
tics, etc.)  without  being  forced  to  worry  about  the  chemical  pro- 
perties of  these  objects.  It  is  generally  not  necessary,  for 
example,  that  all  units  in  the  organization  Know  how  to  calculate 
these  abstractions  so  long  as  tney  are  done  correctly.  By  pursu- 
ing the  development  of  abstractions,  whole  hierarchies  of 
abstractions  of  the  Knowledge  which  is  relevant  to  broad  areas  of 
the  organization  can  oe  built  up  over  a period  of  time. 

Of  course,  the  conditions  under  which  an  abstraction  is  valid 
also  must  be  preserved  as  part  of  the  Knowledge  about  it.  For 
example,  a piece  of  Knowledge  might  be  an  abstraction  which  gives 
tne  minimum  caloric  requirements  which  are  needed  by  various 
groups  of  people  to  sustain  life.  Another  piece  of  Knowledge 
might  be  tacts  on  the  allergy  of  given  groups  of  people  to  milK 
products.  ine  first  set  of  Knowledge  would  be  useful  to 
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government  analysts  wno  are  trying  to  identity  base  levels  which 
can  be  used  to  determine  if  a food  program  is  supplying  enough 
nutrition  to  its  recipients.  This  abstraction  (minimum  caloric 
requirements)  might  not  be  valid  for  those  people  wno  cannot 
properly  digest  milk  products.  Therefore,  other  knowledge  must 
oe  used  to  determine  the  alternative  food  choices  which  might  be 
needed  to  help  balance  the  diet  of  persons  who  cannot  consume 
milk  products. 

2.5  KNOWLEDGE  INTERACTION 

mere  is  a very  close  relationship  among  factual,  procedural, 
and  Judgmental  knowledge  and  it  is  not  always  obvious  to  which 
category  a given  item  belongs.  in  daily  processing  done  by  an 
organization,  data  may  oe  massaged  by  different  procedures  and 
additional  knowledge  abstracted  out  by  different  elements  to 
satisfy  their  own  purposes.  The  data  may  be  kept  in  a single 
pool  which  is  accessed  in  parallel  by  the  various  elements,  or  it 
may  oe  passed  sequentially  from  one  element  to  the  next  with  each 
division  acting  autonomously  upon  it.  There  is  also  the  need  to 
pass  tne  tactual  knowledge  (i.e.,  processed  or  aostracted  data) 
from  one  division  to  another.  Each  division  may  take  incoming 
data  and  process  it  to  create  new  tactual  knowledge  or  new  pro- 
cedural knowledge  with  the  results  being  passed  on  to  the  next 
group.  Where  value  is  added  at  a given  step  of  the  process,  it 
snould  De  possiDle  to  preserve  that  added  value  (new  factual  or 
procedural  knowledge)  for  subsequent  steps.  As  data  is  passed 
from  group  to  group,  each  group,  in  turn,  applies  its  unique  pro- 
cedural knowledge  to  manipulate  the  data  further  and  to  derive 
new  knowledge  from  it  before  passing  it  on  to  the  next  organiza- 
tion. The  process  repeats  itself  many  times  in  the  department 
with  each  organization  receiving  data,  producing  other  factual 
knowledge,  and  aos tract ing  new  knowledge. 

By  a slightly  different  process,  the  procedural  and  judgmen- 
tal knowledge  which  a group  develops  can  also  be  passed  along  to 
other  groups.  This  can  De  in  the  form  of  instruction  on  tech- 
niques, comprehensive  summaries  of  the  history  of  a particular 
proolem  area,  comments  on  tne  significance  of  certain  pieces  of 
information,  or,  perhaps  more  importantly,  as  forecasts  about 
some  future  events.  For  example,  one  group's  tactual  knowledge 
(an  economic  forecast  by  the  Economic  Research  Service)  can 
oecome  another  group's  data  (one  of  many  inputs  which  Congress 
uses  to  decide  what  legislation  is  needed).  In  tact,  the  receiv- 
ing group  (Congress)  may  oe  as  interested  in  the  techniques  (pro- 
cedural knowledge)  and  the  data  (factual  knowledge)  which  the 
generating  group  (ERS)  used  to  create  the  forecasts  as  they  are 
in  tne  forecasts  themselves.  In  effect,  tney  are  seeking  some 
measure  of  validity  and  reliability  for  evaluating  the  forecasts 
which  they  receive.  The  formalization  of  ERS's  procedural  and 
tactual  knowledge  is  necessary  it  such  measures  are  to  be  pro- 
vided. 

Because  of  the  need  for  interaction,  no  single  piece  of 
knowledge  is  very  useful  Dy  itself.  Facts  without  procedures  to 
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manipulate  them  or  witnout  goals  to  satisfy  are  of  little  worth. 
Tne  converse  is,  of  course,  equally  true.  Goals  without  data  to 
work  on  or  techniques  to  apply  are  empty  dreams.  Hence,  large 
portions  of  knowledge  of  different  types  (factual,  procedural, 
and  judgmental)  are  necessary  before  useful  work  can  be  performed 
by  a department.  Indeed,  the  degree  of  interaction  among  the 
various  types  of  knowledge  in  an  enterprise  reflects  the  complex- 
ity of  the  activity  in  whicn  the  enterprise  is  engaged. 

There  is  considerable  communication  of  knowledge  between  the 
departments  of  the  legislative  and  executive  branches.  This  com- 
munication has  been  primarily  factual  knowledge  but  recently 
increasing  amounts  of  procedural  knowledge  have  begun  to  be 
exchanged  as  well.  Some  of  this  communication  occurs  during 
Congressional  hearings,  but  it  can  also  take  the  form  of  reports 
or  estimates  prepared  by  a department.  A department  also  might 
be  called  upon  to  defend  the  methods  of  analysis  which  were  used 
to  produce  the  reports  or  estimates.  In  the  future,  knowledge 
sharing  potentially  could  take  the  form  of  on-line  requests  for 
information  retrieval.  Similarly,  Information  service  requests 
should  be  expected  from  the  public  at  large.  In  any  case,  the 
possible  benefits  of  improved  knowledge  communication  throughout 
government  and  especially  between  the  government  and  its  citizens 
make  it  worthwhile  to  explore  the  potential  for  knowledge  shar- 
ing. 

2.6  THE  RELATIONSHIP  OF  TIME  TO  KNOWLEDGE 

Time  is  a concept  which  applies  to  the  entire  taxonomy  of 
knowledge.  what  is  known  by  an  organization  is  relative  to  some 
point  in  time,  either  the  past,  the  present,  or  the  future.  A 
problem  concerning  the  time  dimension  can  arise  because  of 
today's  data  management  software  which  is  used  to  manage  portions 
of  the  tactual  knowledge  of  an  organization.  In  such  software, 
the  concepts  of  time  must  be  supplied  by  the  human.  The  system 
treats  everything  as  though  it  exists  in  the  present.  Questions 
concerning  the  past  must  be  referred  to  archival  data  bases  which 
then  provide  the  context  of  "the  present"  for  a particular 
request.  As  data  bases  are  connected  via  computer  networks 
(e.g.,  ARPANET,  INFONET),  the  concept  of  time  context  for  each 
data  base  will  Decome  extremely  important.  For  example,  ques- 
tions on  the  amount  of  dollars  which  are  devoted  to  transporta- 
tion can  have  several  different  answers  depending  on  the  time 
context  involved,  i.e.,  which  budget  year  is  involved.  Because 
of  questions  such  as  the  one  just  mentioned  the  issue  of  time 
context  for  the  retrieval  of  tacts  is  frequently  an  important 
one . 

Similar  problems  can  arise  with  other  aspects  of  time  as  it 
relates  to  dealing  with  tactual  knowledge.  The  concept  of  time 
intervals,  e.g.,  "yearly  budget  figures",  requires  a notation  of 
time  in  the  data  to  a level  of  detail  commensurate  with  the  kinds 
of  questions  anticipated  (yearly  figures  are  not  sufficient  to 
answer  questions  which  need  a month-  by-month  breakout). 
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Cnanges  in  the  structure  of  a data  base  (i.e.,  the  metadata) 
can  invalidate  requests  for  information  from  that  data  base. 
Questions  which  used  to  be  answerable  may  no  longer  be  so,  or 
questions  which  are  answerable  now  may  not  work  against  old  ver- 
sions of  the  data  base  in  archival  storage.  For  example,  the 
Department  of  Transportation  is  a relatively  new  department  so 
that  requests  for  tacts  concerning  the  expenditure  of  transporta- 
tion funds  or  tor  facts  which  trace  the  creation  of  a particular 
transportation  policy  would  not  succeed  if  attempts  were  made  to 
seek  all  answers  relative  to  DOT.  Other  departments  and  agencies 
made  transportation  policy  and  expended  transportation  dollars 
before  DOT  was  created. 

Time  dependencies  apply  to  procedural  knowledge  as  well  as  to 
tactual  Knowledge.  Some  heuristic  knowledge  may  De  transformed 
into  algorithmic  knowledge.  For  example,  observations  on  rates 
of  types  of  crime  may  be  compared  with  certain  economic  indica- 
tors. The  results  of  the  comparison  may  lead  the  analyst  to 
develop  a set  of  formulas  which  can  project  increases  in  certain 
types  of  crime  based  on  specific  economic  indicators.  Algo- 
rithmic knowledge  whicn  is  available  may  no  longer  apply  to  a 
particular  problem  area  (tor  example,  conversion  of  Federal  work- 
ers from  their  own  retirement  system  to  the  social  security  sys- 
tem would  make  all  of  the  old  retirement  formulas  obsolete).  It 
becomes  crucial,  then,  to  keep  track  of  the  time  associated  with 
procedural  knowledge  and  with  the  factual  knowledge  it  is  to  pro- 
cess in  order  to  keep  them  synchronized. 

Judgmental  knowledge  requires  an  explicit  time  context  also. 
Daws,  rules,  and  regulations  are  subject  to  change  with  the  pas- 
sage of  time.  What  is  permitted  or  legal  today  may  not  be 
acceptable  tomorrow  or  it  may  not  have  been  acceptable  yesterday. 
Concepts  of  ethics,  values,  and  morals  also  change  over  time. 
Hindsight  analysis  of  past  decisions  requires  an  understanding  of 
tne  environment  at  the  time  a decision  was  made.  Future  analysis 
requires  the  ext r apo 1 at  ion  of  several  alternative  future  environ- 
ments so  that  desired  paths  can  be  selected.  Reactive  decisions 
require  an  understanding  of  the  way  things  are  today  and  hence 
need  up-to-date  Knowledge. 

As  departments  try  to  preserve  more  and  more  of  their 
Knowledge  in  computerized  systems,  the  time  dimension  will  become 
more  important.  In  the  future,  requests  of  the  knowledge 
resource  will  have  to  specify  a time  parameter  in  order  for  the 
Knowledge  to  be  meaningful. 
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3.  KNOWLEDGE  independence  and  context 

3.1  KNOWLEDGE  INDEPENDENCE 

Obtaining  a high  degree  ot  independence  among  the  various 
forms  of  Knowledge  is  a primary  goal  of  Knowledge  management.  By 
Knowledge  independence  we  mean  the  separation  ot  tactual 
Knowledge  (data  or  information)  from  the  procedural  Knowledge 
which  is  used  to  access  or  employ  that  information  and  the  judg- 
mental Knowledge  which  is  used  to  direct  the  organization's 
cictivities.  Such  a separation  is  crucial  to  the  long-term  sur- 
vivability and  utility  of  a department's  Knowledge  resource.  By 
providing  Knowledge  independence,  facts  will  be  more  readily 
usable  by  multiple  procedures  (data  sharing),  and  procedures 
should  be  more  amenable  to  running  with  multiple  sets  of  facts 
(tool  flexibility).  The  separation  of  algorithmic  from  heuristic 
Knowledge  can  provide  a rational  basis  for  understanding  the 
Kinds  of  procedures  which  must  be  translated  into  software  for 
the  computer  systems.  Indeed,  the  separation  of  data  from  pro- 
cedures and  procedures  from  each  other  is  a basic  tenet  of  the 
discipline  ot  software  engineering  (16,17),  Finally,  the  recog- 
nition ot  the  importance  ot  the  human  role  in  managing  judgmental 
Knowledge  is  crucial  when  attempts  are  made  to  automate  pro- 
cedures which  rely  heavily  on  this  type  of  Knowledge.  Ultimately 
achieving  Knowledge  independence,  however,  will  require  some 
canonical  self-describing  representation  of  Knowledge  (not  only 
data,  but  procedures).  This  is  a research  area  which  is  now 
under  investigation  at  a variety  ot  research  institutions  118). 
indeed,  many  ot  these  other  points  are  being  pursued  by  the 
industry  today  (although  not  under  the  collective  name  of 
Knowledge  independence).  Basic  software  engineering  techniques, 
data  and  procedure  independence  of  data  base  management  systems, 
and  procedural  Knowledge  independence  of  Knowledge-based  systems 
an  are  steps  in  the  direction  of  general  Knowledge  independence. 

Another  important  aspect  of  Knowledge  independence  is  the 
need  to  separate  the  various  subject  matter  (or  context- 
Knowledge)  required  of  analysts  so  that  they  can  concentrate  on 
their  resoective  areas  of  special izat ion  (e.q.,  economics) 
without  wasting  valuable  time  learning  extraneous  details  from 
other  contexts  (e.g.,  computer  protocols).  We  agree  that  some 
degree  of  understanding  about  other  contexts  is  both  useful  and 
desirable  lor  each  analyst  in  a department,  but  we  contend  that 
requiring  too  much  understanding  can  be  counter-productive.  The 
challenge  of  Knowledge  management  is  to  discover  and  develop  the 
right  blend  of  Knowledge  independence  to  produce  the  best  possi- 
ble Knowledge  environment. 

3 .2  KNOWLEDGE  CONTEXT 

In  order  to  maKe  the  Knowledge  taxonomy  relevant  to  a partic- 
ular enterprise,  it  is  necessary  to  consider  the  environment  of 
that  organ i zat i on . By  environment,  we  mean  the  context  or  sub- 
ject matter  ot  the  Knowledge  which  is  relevant  to  the  enterprise. 
For  the  ourposes  of  this  paper  we  find  it  convenient  to  divide  a 
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department's  corporate  Knowledge  into  three  contexts:  mission, 
tools  and  support,  and  direction.  Each  ot  these  three  contexts 
can  oe  further  divided  into  Knowledge  of  the  appropriate  sKills 
and  Knowledge  of  a particular  target.  These  areas,  in  turn,  con- 
sist of  factual,  procedural,  and  judgmental  Knowledge  which  are 
relevant  to  the  particular  context.  Figure  3-1  depicts  this 
organization  of  a department's  Knowledge  by  context. 
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3.2.1  MISSION  CONTEXT 

Knowledge  in  the  context  of  a department's  mission  involves 
numerous  skills  such  as  economics  or  statistics.  Knowledge  also 
involves  understanding  a variety  of  target  areas  (including  geo- 
political units  such  as  South  America  or  interest  areas  such  as 
cereal  grain  production).  Geopolitical  units  are  sometimes  used 
to  divide  interest  areas  into  smaller  sets.  The  converse  is  also 
true.  The  primary  activity  contained  in  the  mission  context  is 
what  is  usually  termed  applications.  Analysts  (e.g.,  economists) 
who  are  concerned  with  particular  applications  (forecasts  on 
cereal  grain  production)  require  substantial  knowledge  about 
their  application.  Additional  knowledge  about  the  computers  used 
in  the  tool  context  can  be  nelpful,  but  the  valuable  time  spent 
in  training  the  analyst  to  function  effectively  in  the  computer 
context,  could,  perhaps,  be  better  used  to  improve  the  analyst's 
skill  or  target  knowledge.  Oftentimes  the  trade-off  is  such  that 
the  savings  in  computational  time  fully  warrants  the  training 
time  required  before  an  analyst  can  master  the  machine;  but  many 
times  it  does  not.  It  is  important  to  keep  clear  the  distinction 
oetween  that  portion  of  the  analyst's  time  which  is  spent  acquir- 
ing specialized  skills  and  target  knowledge  and  the  time  which  is 
spent  wrestling  with  awkward  computer  protocols  and  query 
languages  (the  tools  and  support  context).  The  computer  can  be  a 
great  time-saver,  but  it  can  also  be  a great  time-consumer.  Fig- 
ures 3-2  and  i-3  snow  some  examples  of  the  different  types  of 
knowledge  required  by  skills  and  target  areas  in  the  mission  con- 
text. 
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3.2.2  TOOLS  AND  SUPPORT  CONTEXT 

The  context  of  tools  and  support  involves  skills  and  target 
areas  which  are  very  different  from  those  needed  in  the  applica- 
tions relevant  to  the  mission  context.  In  this  context  we  group 
activities  which  deal  primarily  with  the  development  and  mainte- 
nance of  tools.  Also  included  are  functions  which  are  done  in 
support  of  out  not  directly  related  to  a department's  mission. 
Such  activities  might  include  contracting#  personnel,  desks  and 
furnishings,  mathematics,  and  computers.  This  last  category  is 
of  particular  relevance  to  the  concepts  of  this  paper,  and  we 
snail  concentrate  on  the  computer  as  the  primary  tool  of 
interest.  Skills  such  as  programming,  systems,  operations,  and 
so  forth  require  considerable  training  and  involve  general 
aspects  which  apply  to  a variety  of  target  machines.  Targets 
such  as  particular  mainframes  or  individual  terminal  types  form 
the  oasis  of  reality  to  which  the  general  computer  skills  must  be 
applied.  doth  kinds  of  knowledge  are  important  in  understanding 
the  computers  in  the  tools  and  support  context.  Section  6.3  pro- 
vides a Physical  View  of  a hypothetical  knowledge  resource  by 
describing  the  Physical  environment  of  the  tools  and  support  con- 
text. Such  a view  is,  of  course,  essential  to  the  overall 
management  of  a knowledge  resource.  Figures  3-4  and  3-5  show 
some  examples  of  the  different  knowledge  skills  and  targets 
required  in  order  to  understand  fully  the  Physical  View. 

From  the  mission  or  direction  contexts  the  tools  and  support 
context  is  oftentimes  viewed  as  an  overhead  function,  and  the 
users  in  these  areas  generally  resent  being  required  to  master 
the  knowledge  relevant  to  this  context.  The  result  has  been  a 
rather  strong  and  sometimes  vocal  resistance  by  these  users  to 
learning  "extraneous"  knowledge  about  computers.  IBM's  Job  Con- 
trol Language  (JCL)  is  a good  example  of  an  awkward  computer  con- 
text interfering  with  the  applications  context  which  the  analyst 
understands.  The  formulation  of  a working  set  of  JCL  commands  is 
largely  a heuristic  process  which  involves  a great  deal  of  under- 
standing about  the  computer  context  (more  than  applications  peo- 
ple or  managers  care  to  know).  Hence,  the  situation  is  quite 
common  that  once  an  analyst  gets  a JCL  deck  that  works,  that  deck 
is  passed  around  the  office  and  everyone  else  copies  it  rather 
than  try  to  learn  the  heuristics  involved  with  formulating  JCL 
commands. 

The  failure  to  define  formally  the  procedural  knowledge 
(especially  the  heuristic  knowledge)  needed  to  operate  in  the 
computer  context  has  forced  many  departments  to  invest  vast  sums 
of  resources  in  training  tneir  applications  and  management  users 
in  a secondary  context.  New  techniques  are  needed  which  will 
allow  those  trained  in  the  tools  and  support  context  to  define 
the  heuristics  needed  to  access  other  types  of  knowledge  which 
might  be  stored  in  tne  computers.  The  need  to  share  computer 
context  heuristics  with  otners  is  increasing  as  it  becomes  more 
costly  to  train  the  users.  The  technology  of  knowleage-based 
systems  (see  Section  5.1.6)  is  already  being  applied  to  the  prob- 
lems of  accessing  a computer  network  and  particular  data  bases. 
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3.2.3  DIRECTION  CONTEXT 

The  context  of  direction  (or  management)  spans  both  the 
applications  and  the  tools  and  support  contexts.  Correspond- 
ingly, we  identify  three  types  of  management:  the  management  of 
applications,  the  management  of  tools  (in  particular,  computers), 
and  the  management  of  other  managers.  As  with  the  other 
Knowledge  contexts,  the  direction  context  involves  both  skills 
and  target  Knowledge.  SKills  such  as  budgeting,  personnel,  and 
so  forth  generally  apply  to  all  forms  of  management  regardless  of 
the  target  being  managed.  The  target,  on  the  other  hand, 
corresponds  to  an  existing  organization,  project,  or  operation, 
and  an  effective  manager  will  require  specialized  Knowledge  about 
that  target  in  order  to  manage  it  properly.  Figures  3-6  and  3-7 
snow  some  examples  of  sKills  and  targets  in  the  direction  con- 
text. As  with  the  mission  context,  Knowledge  about  computerized 
tools  can  be  useful  to  assist  the  managerial  process,  but  the 
process  of  acquiring  that  Knowledge  can  also  detract  from  the 
manager's  business  of  managing.  The  trade-offs  must  be 
evaluated.  Section  6.2  examines  the  direction  context  through  a 
Structural  View  of  a department's  Knowledge  resource  and  offers 
some  suggestions  about  the  Kind  of  organizational  structure  which 
might  be  used  to  support  a Knowledge  resource. 
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3.2.4  CONTEXT  INTEGRATION 

Figure  3-8  shows  a Venn  diagram  representation  of  the  three 
Knowledge  contexts  relevant  to  tnis  discussion.  Where  a particu- 
lar piece  of  knowledge  falls  on  this  diagram  is  determined 
largely  oy  the  degree  of  relevance  which  that  item  has  to  one  of 
the  three  contexts.  The  manner  in  which  particular  individuals 
access  and  use  an  organizational  knowledge  resource  is  the  sub- 
ject of  the  Functional  View  presented  in  Section  6.1.  In  that 
section,  various  job  categories  will  be  identified  and  placed  on 
the  Venn  diagram  in  an  effort  to  define  clearly  the  role  which 
each  class  is  expected  to  play.  The  need  tor  a coordinated 
understanding  of  the  organization 's  knowledge  resource  should  be 
ODvious  from  this  diagram.  The  acquisition  of  such  a high-level 
view  is  the  subject  of  Section  6. 


Page  3d 


Knowledge  Independence  and  Context 


DIRECTION 

• • 


MISSION 


TOOLS 

AND 

SUPPORT 


CONTEXT  INTEGRATION 


Figure  3-8 


Organizational  Knowledge  Resource 


Page  39 


4.  ORGANIZATIONAL  KNOWLEDGE  RESOURCE 
4.1  THE  DEPARTMENTAL  KNOWLEDGE  RESOURCE 

me  authors  contend  that  a department's  Knowledge,  as 
descrioed  in  Sections  2 and  3,  is  a valuable  corporate  resource 
whicn  must  be  understood  and  handled  effectively.  In  seeking  to 
treat  Knowledge  as  a resource,  an  organization  is  actually  seek- 
ing  to  formally  organize  its  Knowledge  acquisition,  utilization, 
maintenance,  and  preservation  process.  The  emerging  industry 
philosophy  of  treating  data  as  a resource  is  really  just  a way  of 
handling  the  acquisition  and  assembly  of  the  factual  Knowledge 
which  will  be  used  by  the  various  Knowledge  applications.  Thus  a 
data  resource  philosophy  is  based  on  the  belief  that  it  is  suffi- 
cient to  improve  the  processing  of  only  the  factual  component  of 
Knowledge.  A Knowledqe  resource  philosophy,  on  the  other  hand, 
is  based  on  the  belief  that  it  is  necessary  to  consider  all  of 
the  Knowledge  of  a Federal  department  and  to  include  as  much  of 
it  as  possible  in  the  Knowledge  resource.  This  is  a recognition 
of  the  fact  that  a department's  ability  to  supply  the  right 
Knowledge  (factual,  procedural,  or  judgmental)  to  decision-makers 
(governmental  and  non-governmental)  at  critical  times  is  a major 
determinant  of  whether  the  organization  is  judged  to  be  a suc- 
cess. 


Throughout  history  an  organization's  Knowledge  has  resided  in 
the  heads  ot  people:  their  understanding  of  the  organization's 
goals,  their  understanding  of  what  constitutes  relevant  factual 
Knowledge,  their  facility  with  algorithms  and  techniques  for 
problem-solving,  their  familiarity  with  the  history  of  various 
proolem  areas,  and  their  Knowledge  of  skills  and  targets  (includ- 
ing the  ability  ot  the  people  to  Keep  up  with  changes  in  any  of 
tne  areas).  Traditionally,  data  has  been  passed  from  analyst  to 
analyst  on  some  form  of  storage  medium  (e.g.,  paper  or  magnetic 
tape),  out  other  forms  of  Knowledge  have  had  to  be  taught.  Asso- 
ciations among  data  items,  together  with  the  rules  and  conditions 
under  which  those  relationships  have  meaning,  have  to  be 
instilled  in  the  minds  ot  each  analyst  along  with  the  reasons  why 
this  Knowledge  is  important  and  why  it  should  be  preserved.  The 
teaching  of  procedural  knowledge  is  also  important  and  it  may 
become  a Iona  drawn-out  process  which  needs  many  explanations  and 
much  on-tne-job  training.  The  teaching  of  judgmental  Knowledge 
is  even  more  difficult.  In  any  case,  depending  on  the  nature  of 
the  type  of  knowledge,  this  educational  process  can  require  many 
years  and  may  consume  a significant  portion  of  an  organization's 
resources.  This  situation  is  not  unique  to  government,  of 
course.  In  fact,  certain  studies  indicate  that  approximately  20% 
ot  tne  u.  s.  Gross  National  Product  is  currently  devoted  to  such 
xnowledge-transf eral  activities  (15). 

It  is  becoming  clear  tnat  the  transmittal  ot  knowledge  from 
individual  to  individual  within  the  government  is  growing 
increasingly  expensive,  tor  the  amount  of  Knowledge  required  for 
a department  to  function  is  growinq  at  an  ever-increasing  rate, 
A complaint  frequently  heard  from  all  levels  ot  management  is 


Page  40 


Organizational  Knowledge  Resource 


that  oftentimes  it  is  next  to  impossible  to  contact  the  persons 
wno  nave  the  relevant  portions  ot  the  Knowledge  needed  to  answer 
a given  question,  to  perform  a specific  task,  or  to  solve  a trou- 
blesome problem.  Many  times  the  Knowledge  of  whom  to  asK  is  not 
even  available.  Furthermore,  the  cost  of  human  storage  (in  the 
form  ot  employees'  brains)  is  also  going  up.  Perhaps  the  most 
pressing  Knowledge-related  problem  concerns  the  departure  from 
the  government  of  many  of  our  most  respected  and  Knowledgeable 
experts  in  fields  such  as  transportation,  agriculture,  defense, 
nealth,  commerce,  etc.  It  is  essential  that  departments  somehow 
capture  the  unique  Knowledge  which  their  Key  experts  have  before 
it  is  gone  forever.  Publications,  reports,  courses,  textbooKs, 
and  protege-teaching  all  help,  but  a great  deal  of  organizational 
Knowledge  is  being  "preserved"  in  the  form  of  application  pro- 
grams as  tne  computer  is  used  to  perform  more  and  more  data  pro- 
cessing. Anyone  who  has  attempted  to  read  someone  else's  com- 
puter program  code  can  attest  to  the  fact  that,  currently,  com- 
puter programs  are  an  extremely  awKward  form  for  storing 
Knowledge.  The  act  of  documenting  programs  is  an  attempt  at 
writing  down  and  preserving,  in  a form  more  readily  understood  by 
numans,  the  relevant  Knowledge  from  all  three  contexts  of  mis- 
sion, direction,  and  support  which  the  programmer  had  at  the  time 
the  program  was  written.  The  current  emphasis  on  program  docu- 
mentation (both  line-by-line  and  global)  in  government  computer 
centers  and  elsewhere  is  an  open  admission  ot  the  tact  that 
Knowledge  represented  in  the  form  of  computer  program  code  is 
neither  convenient  nor  sufficient  for  long-term  use,  given 
today's  programming  environment. 

Improved  orogramming  languages  and  computational  environments 
(e.g.,  ECL  (19J  might  maKe  the  embedded  Knowledge  more  accessi- 
ble, but  there  will  remain  the  need  for  an  overall  plan  regarding 
the  organ izat ion ' s behavior  with  respect  to  the  effective  sharing 
ot  sucn  Knowledge.  Such  a policy  must  be  based  on  a sound  under- 
standing of  the  organization's  Knowledge.  A model  which  can  be 
used  to  gain  that  understanding  was  presented  in  Sections  2 and 
1.  An  organization  must  develop  some  formal  mechanisms  for 
Knowledge  representation,  Knowledge  acquisition,  knowledge  appli- 
cation, and  Knowledge  preservation.  This  is  not  to  say  that 
humans  should  be  replaced  by  machines,  but  rather,  that  humans 
need  better  ways  to  cope  with  their  Knowledge  problems.  The  dif- 
ficulties lie,  not  so  much  In  quantity  of  Knowledge,  (the  amounts 
are  doubling  approximately  every  five  to  ten  years)  but  in  access 
and  in  understanding.  Improved  Knowledge-access  assistance  is 
already  being  provided  in  tne  fields  of  medicine  and  chemistry 
wnere  Knowledge-based  systems  have  begun  to  demonstrate  remar K- 
abie  capab i 1 i t ies . (More  will  be  said  on  this  subject  in  Section 
b.)  In  any  case,  improved  access  to  an  organization's  Knowledge 
can  allow  organizational  problem-solvers  to  profit  from  the  col- 
lective experience  of  others  in  maKing  their  decisions  by  examin- 
ing the  rules  and  conditions  which  others  have  used  to  solve 
problems  before  them.  such  capabilities  could  enhance  the  day- 
to-day  operations  of  many  Federal  departments. 
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4.2  KNOWLEDGE  MANAGEMENT 

In  Sections  2 and  i we  nave  described  some  ways  ot  categoriz- 
ing Knowledge  wnich  are  useful  to  understanding  what  is  in  an 
organization's  Knowledge  resource.  There  are  several  aspects  to 
the  Knowledge  possessed  by  an  enterprise  and  each  of  these  dif- 
ferent Kinds  ot  Knowledge  requires  special  consideration.  The 
Key  to  understanding  this  conglomerate  of  Knowledge  is  the  con- 
cept of  Knowledge  independence.  What  is  needed  is  a mechanism 
tor  maintaining  each  type  ot  Knowledge  separately  and  independent 
from  the  other  forms.  In  this  fashion  various  pieces  of 
Knowledge  can  be  used  by  different  applications  in  a variety  of 
situations  with  limited  conflict.  Application  of  the  concepts  of 
Knowledge  independence  is  an  overt  recognition  of  the  existence 
of  and  the  differences  among  the  various  types  of  Knowledge  which 
are  each  important  to  the  mission  of  an  organization.  It  is  also 
an  attempt  to  provide  an  environment  conducive  to  Knowledge- 
sharing throughout  a department. 

It  should  be  emphasized  at  this  point  that  a decision  to 
treat  Knowledge  as  a resource  has  implications  tor  the  entire 
organization.  It  is  liKely  that  thousands  of  applications  may 
need  to  access  and  use  a Knowledge  resource.  These  applications 
are  best  understood  and  managed  by  the  various  technical  special- 
ties of  a department  (such  as  economists,  physicians,  scientists, 
statisticians,  etc.)  which  use  factual  Knowledge  in  their  own 
specialized  ways  by  applying  different  sets  of  knowledge  rules 
and  techniques  (procedural  Knowledge).  With  the  advent  of  a 
Knowledge  resource,  specialists  will  continue  to  need  to  build 
their  own  sets  ot  procedural  Knowledge.  However,  with  a policy 
which  pushes  for  a Knowledge  resource,  the  organization  should 
begin  to  understand  that  tnere  are  many  underlying  generic  prob- 
lems and  solutions  which  cross  application  boundaries.  These 
general  principles  often  have  oeen  overlooKed  with  a concentra- 
tion on  a single  Knowledge  application.  (The  processes  of  deduc- 
tive inference  are  basically  the  same  across  applications  and  it 
is  liKely  that  one  deductive  inference  tool  could  serve  numerous 
applications).  Indeed,  past  concentration  on  applications  fre- 
quently nas  resulted  in  the  binding  of  facts  to  the  procedural 
Knowledge  ot  the  application  with  a resulting  unavailability  of 
either  the  application's  procedural  Knowledge  or  the 
app 1 icat ion ' s facts  to  other  users.  Even  when  the  data  is  avail- 
able, the  rules  and  conditions  relevant  to  the  data  (i.e.,  the 
procedural  Knowledge)  are  not  generally  readily  available.  Many 
times  the  metadata  and  the  procedural  Knowledge  (if  they  exist  at 
all)  are  buried  in  a morass  of  computer  instructions  implemented 
in  Fortran  or  assembly  language  or  some  other  obscure  form. 
Attempts  to  use  data  without  a proper  understanding  of  what  the 
data  means  can  lead  to  misinterpretation  and  ill-advised  deci- 
sions. Furtnermore,  data  accumulatea  under  these  conditions  has 
little  or  no  long-term  value  for  the  organization  since  the  cost 
of  teaching  lots  ot  people  all  of  the  Knowledge  which  is  neces- 
sary to  understand  the  data  frequently  exceeds  the  value  which 
might  oe  gained  from  that  understanding. 
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The  knowledge-as-a-resource  philosophy  attempts  to  separate 
all  forms  of  Knowledge  in  order  to  insure  the  availability  of  a 
given  form  of  Knowledge  to  the  person  or  the  application  which 
might  require  it.  A basic  premise  of  this  paper  is  that  a 
Knowledge  resource  should  be  provided  to  people  or  to  various 
applications  without  dictating  the  manner  in  which  the  Knowledge 
is  to  be  used.  Factual  Knowledge  (in  particular,  data)  is 
expected  to  comprise  the  largest  portion  of  this  resource  which 
will  be  shared  widely.  The  Knowledge-as-a-resource  philosophy 
lmolles  that  the  concept  of  "ownership  of  shared  data"  must  be 
transferred  to  the  department  as  a whole  in  order  to  insure  that 
the  data  is  put  to  the  broadest  possible  use  and  that  other 
potential  Knowledge  applications  are  considered  before  altera- 
tions which  may  affect  the  general  utility  of  the  data  are  per- 
mitted. One  of  the  most  critical  instances  of  the  conflicts 
which  can  arise  occurs  when  a specific  application  wishes  to 
delete  data  or  r e lat ionships  in  which  it  no  longer  has  an 
interest.  If  the  data  or  the  relationships  are  still  being  used 
py  some  otner  applications,  dire  consequences  can  result  from  the 
first  group's  autonomous  actions.  Some  mechanism  is  needed  to 
protect  the  interests  of  each  organization  in  the  department  and 
to  preserve  the  value  of  the  Knowledge  resource. 

In  the  final  analysis,  data  has  always  belonged  to  the 
entire  organizat ion . At  various  points  in  time,  it  has  been 
placed  under  the  temporary  custodianship  of  various  people  in  the 
organization.  From  custodianship  it  was  a relatively  simple  step 
to  oarochialism  about  the  ownership  of  data.  Individuals  began 
to  believe  that  data  belonged  to  them  and  not  to  the  organiza- 
tion. While  some  people  have  viewed  this  move  as  unexpected,  it 
was  almost  inevitable  once  users  began  to  embed  procedural 
Knowledge  in  the  organization  of  their  data.  (For  example,  the 
order  of  records  in  a file  may  nave  some  special  significance  for 
an  app 1 icat ion . ) Since  applications  hold  the  purview  over  their 
procedural  Knowledge,  they  naturally  extend  that  purview  to  the 
data.  Knowledge  independence  (see  Section  3.1)  is  the  Key  to 
resolving  the  question  of  data  ownership  because  the  data  can 
then  oe  shared  on  a wide  basis  witnout  the  necessity  for  indivi- 
dual ownership.  A department  must  begin  to  encourage  users  to 
concentrate  on  building  and  improving  their  procedural  Knowledge 
oases  while  taKing  vigorous  steps  to  provide  the  data  resource 
which  these  knowledge  bases  will  need.  Such  steps  might  include 

(1)  adoptina  data  case  management  systems  which  support 
the  explicit  use  of  metadata 

(2)  separating  programs  from  the  data  which  the  employ 

(3)  adopting  software  engineering  techniques  to  build 
shared  software  libraries  of  procedural  Knowledge 

(4)  adopting  Know  ledge-based  system  technologies  tor 
limited  reasoning  caoabilities  coupled  with  access  to 
large  amounts  of  factual  Knowledge. 
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It  data  Is  to  be  shared  among  the  various  elements  and  knowledge 
applications  of  the  department  (where  appropriate)  then  the  data 
must  belong  to  the  department  itself  and  not  to  some  subdivision 
(or  app 1 lcat ion ) . Organizational  success  in  separating  its  fac- 
tual and  procedural  knowledge  is  the  key  to  this  sharing.  At  the 
same  time,  organizational  control  must  be  exercised  through  some 
mechanism  where  decisions  can  be  made  for  the  good  of  the  depart- 
ment as  a whole,  where  priorities  can  be  established  and  main- 
tained deliberately,  and  where  directories  on  the  knowledge 
resource  can  be  kept  current.  Such  a mechanism  can  provide  the 
foundation  upon  which  the  management  of  knowledge  should  be 
based . 

Many  new  tools  and  technigues  will  be  necessary  in  order  to 
transform  Knowledge  into  a departmental  resource.  Many  new  and 
unusual  problems  may  arise,  and  changes  in  managerial  attitude 
and  organization  may  be  required.  In  the  following  sections  we 
describe  a methodology  for  implementing  a knowledge  resource  in  a 
department.  we  propose  a system  architecture  based  on  the  con- 
cept of  maintaining  knowledge  independence  which  is  geared  toward 
providing  a large  deqree  of  flexibility  to  both  the  end-users  and 
the  system  designers.  we  also  identify  a set  of  functions  which 
we  feel  will  be  necessary  if  a department  is  to  develop  knowledge 
into  a departmental  resource.  finally,  in  Appendix  A-l  we  offer 
a discussion  of  the  kinds  of  research  activities  which  will  be 
needed  to  support  a knowledge  resource.  One  set  of  such  activi- 
ties which  are  already  underway  and  which  deserve  special  con- 
sideration is  the  topic  of  Knowledge-Based  Systems.  This  subject 
is  addressed  in  the  next  section. 
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b.  KNOWLEDGE-BASED  SYSTEMS 

The  technology  ot  Knowledge-based  systems  appears  to  hold 
great  promise  tor  providing  many  ot  the  techniques  and  theories 
that  will  be  needed  to  implement  a Knowledge  resource.  By  a 
Knowledge-based  system  we  mean  a system  which  employs  sources  of 
specialized  procedural  Knowledge  about  a particular  problem 
domain  or  problem-solving  behavior  in  order  to  accomplish  some 
tasK  more  ettectively.  such  systems  differ  from  conventional 
computer  programs  (which  nave  their  procedural  Knowledge  embedded 
deeply  within  the  program)  in  that  their  Knowledge  is  represented 
explicitly  and  separately  from  the  code  of  the  program  which 
accesses  and  uses  that  Knowledge.  It  is  also  important  to  note 
that  Knowledge-based  systems  deal  with  the  processing  of  symbolic 
information  as  opposed  to  numerical  computation.  Such  symbolic 
processing  requires  a different  orientation  of  thinKing  about  a 
particular  problem  area  from  the  earlier  "data  processing" 
approach. 

b . 1 EXAMPLES 

Knowledge-based  systems  have  been  developed  to  produce  useful 
results  in  a number  of  diverse  technical  areas.  Some  of  these 
areas  include  mathematical  symbol  manipulation  (MACSYMA),  human 
speech  understanding  ( HEARSAY- 1 1 ) , chemical  analysis  of  mass 
spectral  data  (DENDRAL),  medical  diagnosis  of  disease  (MYClh  and 
DIALOG),  signals  analysis  (HASP),  computer  networK  protocols  and 
terror ist-tracKinq  (RITA),  and  the  representation  and  analysis  of 
pictorial  information  (VIKING  Mars  probe).  In  the  following  sec- 
tions we  briefly  describe  these  systems.  Admittedly,  neither  the 
list  nor  the  discussion  is  complete.  Our  Intention  is  that  these 
sections  serve  only  to  give  an  indication  of  the  existence  of 
sucn  software  and  how  it  has  oeen  used.  Further  investigation  of 
this  tecnnoloqy  by  the  various  departments  is  suggested  if  they 
are  to  determine  how  the  existing  technology  can  be  applied  to 
their  situations. 

b.l.l  MACSYMA 

Engineers  and  applied  mathematicians  generally  could  use  com- 
puter assistance  in  non-numer ical  methods  of  analysis  (e.g.,  sym- 
bolic integration).  MACSYMA  [ 2 0 J is  a Knowledge-based  system 
developed  at  Massachusetts  Institute  of  Technology  which  performs 
a wide  variety  of  symbol  manipulation  functions.  Indeed,  MACSYMA 
nas  already  been  used  successfully  by  mathematicians  over  the 
ARPANET  to  solve  difficult  symbol  manipulation  problems. 

b.1.2  HEARSAY- I 1 

Speech  understanding  j.s  an  area  of  considerable  interest  to 
many  segments  of  the  government.  The  HEAPSAY-II  system  121)  from 
Car ne g ie- -le  1 1 on  University  is  a Knowledge-based  approach  to  this 
problem.  I he  goal  of  the  HEARSAY-11  system  is  the  understanding 
of  continuous  speech  in  sentence  units.  HEARSAY-I I is  of  partic- 
ular theoretical  interest  for  its  ability  to  employ  Knowledge 
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from  a ni.erarchy  ot  domains.  The  domains  of  Knowledge  which  are 
relevant  to  speecn  understanding  include  waveforms,  phonemes, 
syllables,  words,  phrases  and  sentences.  In  HEARSAY,  Knowledge 
about  a particular  subproblem  in  speech  understanding  can  be  used 
by  modules  attacKing  other  subproblems  to  assist  in  their  reason- 
ing. Kor  example,  Knowledge  about  the  construction  of  words  in 
spoKen  language  may  oe  used  to  assist  the  module  concerned  with 
the  translation  of  waveforms  into  possible  utterances.  This  type 
ot  approach  might  be  used  in  Knowledge-based  approaches  which 
need  to  correlate  Knowledge  from  a variety  of  sources  and  in  a 
variety  of  forms. 

5.1.3  DENDRAL 

DENDRAL  122J  is  a system  developed  by  researchers  at  Stanford 
University  to  aid  chemists  in  the  analysis  of  mass  spectral  data. 
DENDRAL  nas  embedded  within  it  sets  of  rules  (see  Section  5.1.9) 
which  express  many  chemists'  Knowledge  about  mass  spectrometry. 
Chemists  are  able  to  extend  the  system's  Knowledge  by  adding 
rules  that  apply  to  new  classes  of  chemical  compounds.  To  date, 
the  results  from  DENDRAL  analyses  have  been  significant  enough  to 
oe  published  in  the  cnemical  literature  (rather  than  the  computer 
literature).  Even  though  only  a few  departments  might  be 
interested  in  mass  spectrometry,  the  idea  of  identifying  rules 
whicn  can  explain  observed  patterns  in  data  is  a classic  form  of 
analysis  which  can  apply  to  many  problem  areas.  In  fact,  the 
concepts  embodied  in  DENDRAL  have  already  begun  to  be  applied  to 
other  problem  domains. 

5.1.4  MYCIN 

l’ he  MYCIN  system  [23J  was  developed  as  a joint  project  by  the 
computer  science  and  medical  departments  ot  Stanford  University 
and  it  is  being  successfully  used  to  assist  physicians  with  the 
diagnosis  ot  disease  and  the  selection  of  appropriate  therapy  for 
patients  with  bacterial  infections  ot  the  blood.  The  Knowledge 
oase  of  the  system  contains  about  200  rules  on  some  fifty  micro- 
organisms and  on  approximately  twenty  antimicrobial  agents. 
After  being  given  some  clinical  data  by  a physician,  MYCIN 
attempts  to  determine  whether  a patient  has  a significant 
disease.  It  then  tries  to  infer  the  liKely  cause  and,  it  possi- 
ble, selects  one  or  more  recommended  therapeutic  agents.  There 
may  be  a direct  analogy  between  this  type  of  medical  diagnosis 
and  many  other  types  ot  diagnosis  which  government  analysts  per- 
form daily.  Ihe  researchers  at  Stanford  have  recognized  this  fact 
and  they  are  worKing  on  a MYCIN-liKe  system  which  can  be  used  in 
non-medical  problem  domains. 

5.1.5  HASP 

Signals  analysis  functions  performed  in  different  departments 
may  find  a direct  analog  in  the  HASP  system  [ 2 4 J at  Systems  Con- 
trol, Inc.  HASP  has  been  designed  to  perform  analysis  on  signals 
obtained  from  multiple  sources  and  has  been  used  to  predict  pat- 
terns in  incoming  data.  LiKe  HEARSAY-11,  HASP  is  capable  of 
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correlating  knowledge  trom  a variety  of  problem  areas.  The 
developers  of  HASP  believe  that  it  will  be  possible  to  produce  a 
HASP-like  system  which  will  work  in  other  problem  domains. 

6.1.6  RITA 

RITA  C 2 5 J is  a system  which  is  based  on  the  MYCIN  work  but 
whicn  was  developed  by  the  Rand  Corporation  to  run  on  a PDP  11 
minicomputer.  A computer  network  protocol  application  has  been 
developed  whicn  provides  a generalized  interface  to  the  APPAnet, 
This  work  is  thought  to  be  directly  transferable  to  any  APPAnet- 
like  network  which  has  an  associated  terminal  subsystem  which  can 
run  RITA.  Some  specialized  knowledge  about  unique  eccentricities 
of  these  different  networks  may  be  needed,  but,  in  general,  the 
tecnnigues  should  be  similar. 

A terror i st-tracking  application  on  PITA  would  also  appear  to 
oe  relevant  to  government  agencies  which  have  been  charged  to 
protect  the  united  States  from  terrorists'  activities.  In  this 
application  the  system  has  knowiedge  on  various  terrorists 
groups,  and,  given  an  event,  RITA  attempts  to  infer  which  group 
was  responsible  for  the  act,  what  the  group's  goals  are,  and 
which  negotiator  would  be  the  best  person  to  deal  with  this 
group . 

A third  application  of  RITA  is  as  an  interface  to  the  New 
York  rimes  Data  Base.  The  New  York  Times  Data  Base  uses  a com- 
plex and  contusing  (to  a naive  user)  protocol  and  syntax  for  its 
queries.  RITA  has  rules  which  specify  how  correct  syntax  for 
queries  is  produced  and  the  system  is  able  to  use  its  rules  to 
generate  queries  which  the  Times  Data  Barse  system  will  accept. 
Similar  activities  of  Interfacing  to  other  data  base  management 
systems  would  also  appear  appropriate.  In  fact,  RITA  has 
already  Deen  linked  to  one  data  base  management  system  (INGRES) 
in  an  early  experiment. 

RITA  exnibits  two  forms  of  inferencing  capability:  goal- 
oriented  and  event-driven  behavior.  The  goal-oriented  mode  is 
similar  to  MYC  IN ' s deductive  capability  where  the  system  is  given 
a goal  state  and  requested  to  determine  how  that  state  can  be 
achieved  (e.g.,  the  terrorist-tracking  application).  The  event- 
driven  oenavior  is  exhibited  in  the  A R PA net  interface  application 
where  the  system  is  given  a task  to  do  and  then  proceeds  to 
accomplish  that  task  by  interacting  with  the  environment. 

5.1.7  DIALOG 

rne  DIALOG  system  1261  developed  by  the  University  of  Pitts- 
burgh is  a diagnostic  consultation  system  tor  internal  medicine. 
It  has  demonstrated  a capacity  for  solving  difficult  clinical 
problems  whicn  are  complicated  by  the  concurrence  of  several 
disease  entities.  A major  reason  for  its  success  is  due  to  the 
tact  that  its  knowledge  base  contains  rules  on  something  in 
excess  of  50%  of  all  known  major  diseases  of  internal  medicine. 
I’ne  rule  sets  about  the  behavior  of  known  types  of  internal 
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diseases  have  been  formalized  and  placed  into  disease  hierar- 
chies. DIALUG  uses  these  rules  to  form  hypotheses.  Kor  example, 
if  DIALOG  has  determined  (cased  on  primary  clinical  data)  that  a 
patient  has  congestive  neart  failure  then  the  next  problem  which 
it  attempts  to  solve  is  to  differentiate  between  pulmonary 
emphysema  and  bronchial  asthma  (both  cause  congestive  heart 
failure).  Supportive  evidence  is  required  to  confirm  one  of 
these  hypotheses.  Once  this  differentiation  is  done,  the  system 
will  proceed  to  work  on  increasingly  more  specific  hypotheses 
wnicn  might  be  related,  for  example,  to  pulmonary  emphysema. 
DIALOG  is  of  particular  interest  to  government  users  because  of 
tne  style  of  inferencing  which  it  employs.  This  type  of 
inferencing  is  called  abduction  (as  opposed  to  the  more  familiar 
forms  of  deduction  and  induction).  Abduction  is  the  form  of 
inference  which  starts  with  a set  of  rules  about  certain  sets  of 
facts  and  guesses  that  a new  given  fact  is  a case  under  a partic- 
ular rule  in  the  set.  DIALOG  also  has  the  ability  to  function 
with  a sizeable  knowledge  base  (10,000  rules).  Undoubtedly,  as 
an  organization  becomes  more  sophisticated  in  their  use  of 
Knowledge-based  systems  the  size  and  complexity  of  their 
knowledge  bases  will  grow.  it  is  not  unreasonable  to  envision 
government  applications  which  require  knowledge  bases  of  this 
magnitude . 

5.1.8  VIKING  MARS  PROBE 

Cal  recn's  Jet  Propulsion  Laboratory  (JPL)  in  association 
with  NASA  has  employed  a knowledge-based  system  in  the  perception 
subsystem  of  the  VIKING  Mars  probe  vehicle  prototype  [27],  This 
knowiedde-oased  system  is  designed  to  perform  an  analysis  of  pic- 
torial information  of  the  terrain  in  the  landing  area  of  the  VIK- 
ING Mars  probe.  Since  NASA  had  never  been  to  Mars,  it  was  diffi- 
cult for  them  to  predict  exactly  what  Mars'  terrain  would  look 
like.  Nhat  will  a picture  of  a rock  on  Mars  appear  to  resemble, 
tor  example?  In  any  case,  there  is  quite  possibly  an  application 
of  this  technology  to  other  government  interests  in  the  process- 
ing of  pictorial  information. 

5.1.9  PRODUCTION  SYSTEMS 

•lost  of  the  knowledge-based  systems  mentioned  above  tall  into 
tne  category  of  Production  Systems.  Knowledge  is  represented  in 
tnese  systems  in  the  form  of  productions  or  rules  which  state 
that  if  a certain  event  is  true  in  the  system's  data  base,  then  a 
certain  action  should  be  taken.  This  action  may,  for  example, 
alter  the  data  base,  or  it  may  perform  some  computation.  Such 
systems  may  be  environment-driven  in  which  actions  occur  as  a 
result  of  conditions  arising  (as  in  the  RITA  network  protocol 
system),  or  they  may  oe  goal-driven  in  which  backward-chai ning 
through  the  rule  set  is  employed  to  determine  the  set  of  condi- 
tions needed  in  order  tor  a certain  action  to  take  place  (as  in 
MYCIN's  diagnosis  process).' 
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5.2  knowledge:  issues 

There  are  several  important  areas  of  consideration  in 
Knowiedge-oased  system  application.  These  areas  Include 
Knowledge  representation,  acquisition,  and  utilization,  inexact 
inference,  and  explanation.  various  knowledge-based  systems 
offer  different  techniques  tor  representing,  acquiring,  and  using 
Knowledge  as  well  as  methodologies  tor  handling  inferences  under 
uncertainty  and  explaining  to  the  user  why  a particular  conclu- 
sion was  reached. 

\ 

5.2.1  KNOWLEDGE  REPRESENTATION 

Knowledge  representation  deals  with  ways  of  representing 
Knowledge  to  the  system.  These  representations  include  factual 
Knowledge  (such  as  those  based  on  text-book  data),  well-tooled 
models  (such  as  laws  of  physics),  and  heuristic  knowledge  (or 
r uies-of-tnumb  based  on  experience  but  without  formal  proof). 

5.2.2  KNOWLEDGE  ACQUISITION 

Knowledge  acquisition  concerns  the  process  of  extracting 
Knowledge  from  experts  and  transferring  it  to  a form  which  the 
system  can  use.  Most  of  today's  knowledge-based  systems  require 
this  knowledge  acquisition  to  be  done  by  hand  over  an  extended 
period  of  time,  although  some  systems  (e.g.,  METADENDRAL  1 2 8 J ) do 
attempt  to  extract  knowledge  from  sample  data,  i.e.,  they  exhibit 
some  signs  of  primitive  learninq. 

5.2.  i KNOWLEDGE  UTILIZATION 

The  issue  of  knowledge  utilization  is,  perhaps,  of  more 
interest  to  the  end-users,  for  it  is  at  this  stage  that  the 
Knowledge  is  put  to  use.  Some  systems  (notably  HEARSAY-ID 
attempt  to  bring  together  knowledge  from  different  sources  to 
solve  a given  problem.  The  value  in  bringing  together  different 
Kinds  of  Knowledge  is  one  of  the  reasons  why  complex  government 
agencies  such  as  ERDA  are  created. 

5.2.4  INEXACT  INHERENCE 

Inexact  inference  refers  to  the  problem  of  making  inferences 
from  incomplete  or  probabilistic  Knowledge.  This  situation  is 
probably  extremely  prevalent  in  most  government  departments  since 
tne  nature  of  their  business  is  to  piece  together  knowledge  from 
a collection  of  tacts  qleaned  over  time.  Systems  such  as  MYC1N 
can  associate  deqrees  of  certainty  with  individual  rules  and 
thereby  produce  responses  of  the  form  "The  answer  is  most  likely 
( . 7 ) ..." 

5.2.5  EXPLANATION 

A very  useful  aspect  of  many  knowledge-based  systems  is  the 
ability  to  explain  the  system's  line  of  reasoning  to  a doubting 
or  novice  user.  Such  a capability  is  essential  when  critical 
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decisions  are  to  be  made  or  when  (as  will  often  be  the  case)  the 
Knowledge  of  the  system  is  to  be  acquired  and  to  grow  incremen- 
tally. Explanations  can  be  an  Integral  part  of  the  users'  learn- 
ing with  systems  of  this  type. 

The  technology  of  Knowledge-based  systems  is  an  active 
research  area  which  appears  to  have  qooa  potential  for  implement- 
ing specific  Knowledge  applications  in  government  departments. 
Second  generation  Knowledge  applications  are  now  being  developed 
as  tne  technology  matures.  Whart  is  needed  now  is  a study  of  the 
state-ot-the-ar t in  Knowledge-based  systems  and  an  assessment  of 
the  suitability  of  potential  government  applications  for  this 
technology.  The  larger  problem  of  Knowledge-sharing  among  vari- 
ous applications  will  require  extensive  planninq,  thinKing,  and 
experimentation  as  each  department  moves  toward  developing  their 
Knowledge  resource.  The  next  sections  of  this  paper  deal  pri- 
marily with  ways  to  view  a Knowledge  resource  which  can  lead  to 
the  development  of  the  proper  perspective  for  the  implementation 
of  a Knowledge  resource.  These  views  form  the  basis  for  the  log- 
ical system  design  of  Section  8. 
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6.  KNOWLEDGE  RESOURCE  VIEWS 

There  seem  to  be  at  least  three  ways  to  view  the  Knowledge 
resource  in  large,  complex  enterprises  such  as  the  Federal 
Departments:  a Functional,  a Structural,  and  a Physical  View, 
The  Functional  View  emphasizes  the  various  kinds  of  user- 
t unctions  performed  within  the  enterprise  regardless  ot  the 
equipment  or  organization  involved.  The  Structural  View 
describes  the  organization  which  the  enterprise  uses  to  estab- 
lish, build  and  use  its  Knowledge  resource.  The  Physical  view 
depicts  the  physical  or  computer  environment  in  which  the 
Knowledge  is  processed.  These  three  views  are  not  intended  to  be 
mutually  exclusive;  rather,  they  are  intended  to  provide  three 
different  models  of  the  Knowledge  resource  of  an  enterprise.  The 
first  view  identifies  various  needs  ot  each  functional  activity, 
thereby  permitting  optimization  by  specialization  of  function. 
The  second  view  emphasizes  the  organizational  roles  which  people 
play  in  operating  and  using  the  resource.  The  third  view  intro- 
duces the  pnysical  constraints  imposed  by  the  technology  which 
exists  in  the  real  world  and,  at  the  same  time,  points  out  areas 
of  weakness  requiring  additional  acquisitions  or  development  on 
the  part  of  the  enterprise.  These  three  views  are  useful  in 
studying  how  a department  can  best  prepare  for  the  business  of 
handling  Knowledge  so  that  it  may  become  an  organizational 
resource . 

6.1  FUNCTIONAL  VIEW 

From  the  point  of  view  of  functions,  the  knowledge  resource 
of  an  organization  must  service  several  different  Kinds  of  users 
(i.e.,  it  must  serve  many  different  functions).  We  find  it  con- 
venient to  identity  six  general  classes  of  users  of  a Knowledge 
resource:  Clerks,  Managers,  Analysts,  Information  Specialists, 
Programmers,  and  Knowledge  Administrators.  Undoubtedly,  other 
classifications  are  possible.  Figure  6-1  shows  a grouping  ot 
these  functional  users  according  to  their  degree  of  sophistica- 
tion with  a computer  environment  as  opposed  to  their  sophistica- 
tion with  the  applications  which  may  require  some  programs  to  be 
run  on  computers.  In  Section  3.2  we  discussed  three  Knowledge 
contexts  which  are  ot  particular  relevance  to  a department:  the 
mission  context,  tne  tools  and  support  context,  and  the  direction 
context.  The  various  functional  categories  have  a very  definite 
role  with  respect  to  these  contexts.  The  Venn  diagram  of  Figure 
3-8  is  reproduced  in  Figure  6-2,  and  the  various  functional 
categories  are  superimposed  over  it.  df  particular  interest  are 
tne  points  of  Interaction  among  the  three  areas  of  context,  for 
it  is  at  tnese  points  where  Knowledge-sharing  between  contexts 
will  cause  the  most  difficulties. 
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"Clerks"  are  heavily  applications-oriented  witn  specific  and 
somewhat  repetitive  tasks.  Their  application-orientation  is 
reflected  in  Figure  6-2  by  their  placement  entirely  within  the 
mission  context.  Personnel  in  this  category  might  include  census 
takers  who  are  employed  by  the  Bureau  of  the  Census  to  gather  the 
census  data.  rne  personnel  at  the  Veteran's  Administration  who 
prepare  the  forms  which  are  used  to  certify  that  a veteran  is 
eligible  for  benefits  is  another  example  of  people  who  fall  into 
this  category.  Primarily  their  function  is  to  collect  data  for 
the  department  and  to  make  note  of  special  activities  tor  storage 
in  the  knowledge  resource.  They  employ  algorithmic  knowledge  in 
an  applications  context  as  an  integral  part  of  their  job  to  pro- 
vide information  and  to  note  transactions,  but  they  have  very 
little  understanding  of  the  complexities  of  the  otner  knowledge 
activities  which  occur  as  a result  of  their  actions.  They  usu- 
ally have  their  expertise  in  a limited  subject  area.  For  exam- 
ple, a census  taker  might  be  very  skilled  in  getting  the  census 
forms  filled  in,  but  he  or  she  might  not  have  any  idea  of  how  to 
analyze  the  data  which  they  have  collected.  Users  in  this 
category  reguire  conceptually  simple  operations  which  reflect  the 
algorithmic  nature  of  their  jobs.  They  also  require  rapid 
response  to  their  commands  because  of  the  transaction  nature  of 
their  interactions. 

Under  the  category  of  "Managers"  we  have  grouped  all  levels 
of  decision-makers  and  planners  tor  the  department.  Three  types 
of  managers  are  identified:  those  who  manage  applications,  those 
who  manage  computers  or  other  tools,  and  those  who  manage  other 
managers.  Ihe  first  two  categories  require  a blend  of  knowledge 
from  the  management  context  with  either  the  mission  or  the 
computer-tool  context.  This  is  shown  in  Figure  6-2  by  placing 
these  two  types  of  managers  into  both  contexts.  The  Managers 
group  generally  uses  judgmental  knowledge  in  large  quantities  and 
views  the  knowledge  resource  from  the  direction  context.  Their 
function  is  to  receive  and  analyze  requirements,  to  set  goals  for 
the  department,  and  to  see  that  things  run  smoothly  in  attempting 
to  meet  those  requirements.  Members  of  the  Managers  group  employ 
knowledge  in  a largely  heuristic  fashion  to  assist  in  making 
decisions  and  to  experiment  with  hypotheses  (i.e.,  to  play  "what 
if"  games).  From  the  subject  area  perspective,  applications 
managers  have  knowledge  ranging  over  a broader  area  than  either 
clerks  or  analysts.  Similarly,  computer  manaqers  generally  have 
a oroader  knowledge  of  the  computer  context  than  do  programmers. 
A goodly  portion  of  their  knowledge  is  used  to  achieve  proper 
resource  assignment  in  this  context.  Users  in  the  management 
category  need  "natural"  high-level  operations  which  provide 
"know ledge-r ich"  responses  to  a brief  request.  Due  to  (1)  the 
limited  amount  of  time  whlcn  the  members  of  this  group  generally 
have,  (2)  their  relatively  nigh  cost,  and  (3)  the  heuristic 
nature  of  what  tney  do,  training  must  be  be  kept  at  a minimum, 
and  commands  and  protocol  must  oe  easily  recalled. 

"Analysts"  refers  to  tne  large  category  of  government  employ- 
ees whose  knowledge  context  consists  of  a basic  mission  skill 
combined  with  knowledge  about  a specific  geopolitical  target  or 
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subject  area.  Figure  6-2  shows  analysts  contained  within  the 
context  of  their  application.  They  are  highly  trained  in  a 
Knowledge  specialty  other  than  computer  or  information  science. 
Typically,  these  are  the  specialists  who  develop  the  algorithms 
or  the  neuristics  which  are  used  to  process  factual  Knowledge. 
Part  of  their  Knowledge  is  contained  in  the  algorithms  and 
heuristics  they  employ.  This  is,  of  course,  the  ideal  case.  In 
actual  tact,  many  analysts  may  have  been  cross-trained  in  many  of 
tne  sKills  of  the  computer  context.  Some  example  members  of  this 
group  might  be  economists,  statisticians,  transpor tation  special- 
ists, nuclear  physicists,  etc.  Analysts  are  the  most  expert  peo- 
ple in  their  Knowledge  application  area,  but  their  expertise  does 
not  usually  extend  outside  of  a given  Knowledge  sKill  area.  For 
example,  Knowledge  of  nuclear  physics  may  not  help  a person 
decide  on  the  advisability  of  building  a coal  gasification  plant. 
However,  analysts  will  need  and  use  target  Knowledge  (energy 
needs  of  the  United  States  in  1985-1995)  which  is  common  to  many 
other  applications  sKills.  Since  this  group  uses  algorithmic  and 
heuristic  Knowledge  against  the  data  bases  and  the  metadata,  they 
have  oroad  interface  requirements.  Character istic  of  the  members 
of  this  class  is  the  need  to  access  heuristic  tools  and  a need 
tor  flexible  interfaces  tor  accessing  the  Knowledge  resource. 
They  also  require  a set  of  powerful  but  explicit  operations  which 
allows  them  to  state  algorithmic  requests  and  interpret  the 
responses  precisely. 

"Information  Specialists"  are,  tor  the  most  part,  retrieval 
specialists  who  provide  an  information  service  to  the  clerKs, 
analysts,  and  managers.  People  in  this  category  are  generally 
highly  trained  in  the  various  retrieval  mechanisms  (i.e., 
"tools")  which  can  oe  used  to  access  the  data  bases  and  the  meta- 
data. Therefore,  they  need  to  have  some  Knowledge  of  the  com- 
puter context.  They  also  need  to  receive  some  training  in  the 
particular  specialty  areas  of  the  people  whom  they  are  support- 
ing. This  training  enables  them  to  provide  service  in  the  use  of 
algorithmic  Knowledge  which  has  been  implemented  in  computer  pro- 
gram form.  Information  Specialists,  in  effect,  act  as  human 
translators  of  people's  requests  into  machine-oriented  queries 
and,  to  some  extent,  assist  in  the  interpretation  of  the  results, 
information  Specialists  require  access  to  all  the  Knowledge 
resource  facilities  available  (except,  perhaps,  the  heuristic 
facilities).  They  will  need  extensive  and  on-going  training  as 
new  information  processing  tools  are  introduced  and  as  new  data 
oases  are  implemented. 

Tne  tiftn  category  is  "Programmers",  whose  specialty  is  com- 
puter programming.  They,  of  course,  view  the  Knowledge  resource 
from  tne  computer  portion  of  the  tools  and  support  context  as 
shown  in  Figure  6-2.  Programmers  provide  an  oftentimes  necessary 
service  to  other  functional  sets  of  users  where  precise,  repeti- 
tive algorithms  are  required.  :lJJsers  in  this  category  need  to 
become  more  intimate  with  the  internal  workings  of  the  underlying 
software  which  manages  the  data  bases  and  the  metadata.  They  are 
also  frequently  called  upon  to  code  the  algorithmic  Knowledge  of 
certain  anpiication  or  management  sKills  into  computer  programs. 


Knowledge  Resource  Views 


Page  55 


This  latter  need  means  tnat  they  require  very  formal,  very  pre- 
cise interfaces  to  programming  languages  in  order  to  carry  out 
tneir  function, 

Tne  final  group  is  termed  "Knowledge  Administrators",  This 
group  consists  of  three  kinds  of  people,  the  Enterprise  Adminis- 
trator, the  Data  Base  Administrator Cs ) , and  the  Applications 
Administrators,  whose  collective  function  is  to  maintain  an  effi- 
ciently running  and  effective  knowledge  resource,  A detailed 
examination  of  the  Knowledge  Administrators  occurs  in  Section 
6,2,  The  central  role  of  the  Knowledge  Administrators  is  dep- 
icted in  Figure  6-2  which  shows  the  members  of  this  category  as 
dealing  with  all  three  contexts.  Knowledge  Administrators  are 
less  interested  in  obtaining  specific  facts  from  the  knowledge 
resource  and  more  interested  in  monitoring  how  the  knowledge 
resource  is  performing  and  meeting  the  needs  of  the  other  user 
groups.  in  this  capacity  they  will  require  a special  set  of  mon- 
itoring and  statistical  evaluation  tools, 

in  order  to  support  the  continuum  of  user  functions,  three 
oroad  categories  of  software  must  be  considered:  Cl)  the  data 
management  software  which  provides  the  "access  engines"  to  data 
bases  contained  on  some  storage  medium,  (2)  the  procedural- 
oriented  software  (i.e.,  algorithmic  and  heuristic  processes,  and 
(3)  the  user  interfaces  which  must  be  capable  of  providing  the 
widely  disparate  knowledge  application  views  of  the  users  in  the 
six  functional  groups.  This  categorization  highlights  two 
diaine t r lea  1 ly  opposed  aspects  of  information  systems:  machine 
efficiency  and  user  efficiency.  The  three  categories  should  be 
as  independent  as  possible,  although  most  current  commercial 
software  tends  to  tie  the  user  interfaces  closely  to  individual 
data  managers  or  algorithmic  procedures.  Greater  independence  of 
tne  categories  allows  the  users  to  view  the  data  in  ways  which 
are  natural  to  them  and  are  closely  tied  to  the  particular 
knowledge  application  without  forcing  them  to  understand  how  or 
why  choices  of  machine  efficiency  have  been  made, 

6.1.1  KNOWLEDGE  RESOURCE  TOOLS 

The  software  tools  wnich  can  be  useo  to  build  and  access  a 
knowledge  resource  can  be  grouped  into  several  categories  which 
differ  from  each  other  primarily  in  the  deqree  of  logical  struc- 
turing and  independence  of  knowledge  which  each  system  can  accom- 
modate. Figure  6-3  shows  a continuum  of  knowledge  resource  tools 
running  from  the  standard  tile  system  supplied  with  a computer's 
operating  system,  through  tile  management  systems  and  data  base 
management  systems,  to  knowledge-based  systems,  and  finally  to  a 
new  kind  of  system  (to  be  defined  oeiow)  termed  a knowledge  base 
management  system.  These  five  kinds  of  systems  differ  in  tneir 
purpose,  tneir  function,  tneir  capabi 1 i t les , and  the  view  of  data 
and  metadata  wnich  they  provide  to  users.  They  also  differ  in 
their  ability  to  support  the  needs  ot  a knowledge  resource  (the 
independence  of  knowledge  contexts  and  knowledge  forms).  To  sup- 
port systems  wnich  are  intended  to  be  knowledge-based,  the  data 
oase  must  contain  tacts  and  assertions  about  the  world,  must 
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provide  for  relationships  ( metadata ) , must  be  accessiDle  by  a 
wide  range  of  Knowledge  applications,  must  be  of  arbitrary  size, 
and  must  have  no  a priori  constraints  on  the  complexity  of  organ- 
ization. 

Many  varieties  of  the  Knowledge  resource  tools  described  in 
Figure  6-3  are  currently  available,  and,  in  tact,  there  are 
several  such  products  in  different  departments  today.  The  use  of 
these  tools  within  a department  requires  a considerable  learning 
effort  for  each  tool.  Unfortunately,  there  is  no  guarantee  that 
a department  will  be  able  to  get  these  tools  to  function 
together.  what  we  are  proposing  is  a frameworK  for  tying  those 
various  systems  together  so  that  the  Knowledge  which  they  manage 
can  oe  shared  most  effectively  among  themselves  and  with  the 
human  users  which  they  serve.  The  philosophy  of  treating 
Knowledge  as  an  organizational  resource  recognizes  the  need  for 
such  coordinat ion , and  any  methodology  for  implementing  a 
Knowledge  resource  must  taKe  this  aspect  into  consideration. 
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me  standard  tile  system  (SFS)  provides  the  basic  access 
methods  employed  by  the  other,  higher-level  data  managers.  The 
SFS  can  provide  files  directly  to  users  (generally  to  programs  or 
to  a text  editor),  but  they  require  the  user  programs  to  contain 
much  of  the  information  about  the  physical  characteristics  of  the 
tile  and  all  of  the  information  about  the  logical  structure  of 
tne  data.  The  file  is,  in  effect,  a sequence  of  bits  which  is 
meaningful  only  to  tne  Knowledge  application  which  created  it. 

A tile  management  system  ( FMS ) begins  to  allow  rudimentary 
data  description  in  the  form  of  files,  records  within  files,  and 
fields  within  records.  Many  commercial  packages  are  available 
whicm  tall  into  this  category,  including  some  stand-alone 
inverted-t ile  retrieval  systems.  An  FMS  is  designed  to  process 
groups  of  related  data  in  a fast,  cheap  fashion  where  separate 
logical  relationships  among  data  aggregates  (records)  are  not 
necessary.  Such  relationships  are  again  retained  by  the  programs 
wnich  access  the  data  (which  means  that  the  knowledge  is  not 
readily  available  to  other  algorithms  or  heuristic  procedures). 

A data  base  management  system  (DBMS)  maintains  and  provides 
access  to  an  integrated  data  base  of  many  interrelated  data 
aggregates.  Provision  is  made  for  logical  structuring  ot  the 
data  to  reflect  both  abstract  and  physical  relationships.  This 
structure  is  made  explicit  in  the  data  base  itself  (in  the  form 
of  metadata)  and  is  availaole  to  the  DBMS.  This  permits  access 
to  the  description  of  an  entity  (such  as  by  listing  its  attri- 
butes or  characteristics)  independent  of  the  actual  occurrences 
of  entries  tor  tnat  object  in  the  data  base.  For  example,  commo- 
dity sectors  of  agriculture  can  be  divided  into  crop  and  lives- 
toc<  classifications.  Crops  can  oe  further  divided  into  fibers, 
tobacco,  grains,  oil  crops,  fruits,  vegetables,  ornamental 
nlants,  and  sweeteners.  The  attributes  of  the  commodities  can  be 
listed  independent  ot  any  particular  commodity  which  is 
represented  as  an  instance  in  the  data  base.  Furthermore,  an 
integrated  data  base  permits  the  expression  of  multiple  abstract 
relationships  among  data  aggregates  so  that  a department  can 
descrioe  not  only  what  an  entity  is  but  how  it  is  used  by  the 
different  agricultural  subsectors  within  the  economy.  Continuing 
tne  example,  relationships  between  supply  and  demand  with  respect 
to  each  of  the  commodities  need  to  be  recorded.  Ratios  between 
production  costs  and  distribution  costs  are  also  important  and 
need  to  be  noted.  This  type  of  factual  knowledge  could  be  used 
oy  pork  distributors,  for  example,  to  plan  an  advertising  cam- 
paign wnich  might  be  designed  to  offset  an  abundant  supply  of 
pork.  A data  Dase  management  system  permits  an  integrated 
representation  of  data  in  support  of  all  of  these  potential  uses. 

A knowledge-based  system  (KBS)  is  a term  used  here  to 
represent  a new  kind  of  experimental  processing  system  which  is 
not  yet  available  in  tne  commercial  marketplace  (see  Section  S on 
Knowledge-Based  Systems).  A KBS  allows  for  the  representation  of 
rules  ot  logic  and  conditions  for  the  application  ot  these  rules 
to  be  placed  within  the  knowledge  base  and  accessible  to  the  KBS. 
The  KBS  needs  a data  base  and  metadata  aqainst  which  to  apply  its 
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rules.  Most  current  implementations  include  a specialized  DBMS 
ouilt  for  the  particular  knowledge-based  system.  In  this  regard, 
tne  tactual  and  procedural  knowledge  are  not  clearly  separated, 
thus  making  it  difficult  to  share  them  with  other  applications. 

A knowledge  base  management  system  CKBMS)  is  a term  which  we 
nave  coined  to  represent  the  extension  ot  the  knowledge-based 
philosophy  to  include  the  concept  ot  knowledge  independence.  The 
concept  is  a rather  straightforward  extension  of  the  data  base 
philosophy  which  attempts  to  extract  the  logical  structure  of  the 
data  base  and  keep  it  separate  from  programs  ( pr ocedur ized  appli- 
cations knowledge)  which  access  it.  Formally  organizing  and 
representing  knowledge  in  this  fashion  (separate  from  the  appli- 
cations which  employ  it)  is  a positive  step  toward  preserving 
tnis  knowledge  in  a formal  manner  for  future  generations  of 
users.  A knowledge  case  management  system  employs  all  of  the 
other  types  ot  knowledge  software  tools  in  a consistent  fashion 
striving  to  maintain  the  independence  of  the  various  forms  of 
knowledge.  A KBMS  is  the  foundation  upon  which  a department  can 
build  and  manage  its  knowledge  resource. 

Kacn  of  these  kinds  ot  systems  provides  a special  service  to 
tne  enterprise  and  eacn  has  certain  advantages  and  disadvantages. 
SFS  and  FMS  violate  the  knowledge  independence  goals  upon  which  a 
knowledge  resource  is  founded.  Furthermore,  few  people  in  the 
mission  or  direction  contexts  prefer  to  think  of  their  factual 
knowledge  in  terms  ot  strings,  fields,  recoras,  or  files.  How- 
ever, the  claim  has  been  made  by  those  in  the  computer  context 
that  these  systems  provide  higher  degrees  of  processing  effi- 
ciency. in  general,  as  one  moves  from  the  SFS  to  the  KBMS,  one 
presumably  sacrifices  some  ability  to  tinker  with  processing 
efficiency  while  gaining  some  degree  of  programming  or  human 
efficiency  through  knowledge  independence.  The  trade-offs  are 
not  always  clear,  but  in  general  they  hold  true.  Not  all  appli- 
cations, however,  can  afford  a full-fledged  data  base  management 
system.  Designers  of  single-user  systems  with  non-shared  files 
or  special-purpose  real-time  processing  systems  may  find  that  the 
overnead  involved  in  the  generality  of  a DBMS  is  not  cost- 
effective  for  their  application.  Presumably,  then,  an  FMS  or  the 
SFS  would  suffice  by  providing  the  necessary  speed  at  the  cost  of 
increased  programming  and  maintenance  effort  (since  the  pro- 
cedural and  factual  knowledge  will  quickly  become  hopelessly 
intertwined).  Once  this  happens,  of  course,  the  data  will  be 
closed  for  all  other  knowledge  applications.  This  point  is  a 
legitimate  part  of  the  life  cycle  cost  of  a software  system,  but 
one  which  is  rarely  measured  in  today's  environment. 

Many  times  the  question  is  asked  (especially  in  large  system 
development  projects),  "What  is  the  best  DBMS  for  my  system?" 
The  answer  often  comes  back  after  considerable  study  and  evalua- 
tion "None;  but  system  X¥Z  appears  to  be  tne  least  bad."  What 
has  happened,  of  course,  is  that  no  one  DBMS  (or  FMS  or  SFS) 
meets  all  of  the  requirements  of  the  various  knowledge  applica- 
tions of  the  proposed  system.  Some  knowledge  contexts  may  need 
fast  retrieval  but  medium  update  speeds.  Others  may  need 
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complicated  data  structures.  Still  others  may  need  to  store 
"live"  data  very  fast  and  then  process  it  later  in  background 
mode.  The  key  point  is  that  the  system  designer  should  have 
availaoLe  a choice  of  which  kind  of  software  is  most  appropriate 
tor  the  individual  applications  which  the  system  is  to  serve.  No 
single  knowledge  resource  tool  can  properly  service  all  users. 
Beyond  the  variety  of  software,  then,  some  mechanism  will  be 
needed  for  overseeing  tne  usage  of  these  various  knowledge  tools 
and  coordinating  any  interaction  which  may  be  necessary  among 
them  (more  about  tnis  control  mechanism  will  be  presented  in  Sec- 
tion 8 ) . 

In  attempting  to  move  to  a position  where  knowledge  becomes 
an  organizat ional  resource,  a department  will  need  more  than  a 
selection  of  data  management  software;  they  will  need  a formal 
mechanism  for  maintaining  their  heuristic  knowledge  apart  from 
their  applications  software  (which  represent  algorithmic 
knowledge).  As  discussed  earlier  in  this  paper,  knowledge  is 
more  than  structured  data.  It  includes  the  semantics  of  the 
data,  how  the  data  is  to  be  used,  and  the  representation  of  why 
the  data  is  important  to  tne  department.  In  a knowledge  resource 
which  is  meant  to  be  relatively  complete,  some  means  will  have  to 
be  provided  so  that  non-computer ized  knowledge  may  be  represented 
or  accounted  for  in  the  system.  For  example,  the  answer  to  a 
query  of  a KB ms  might  be  a list  of  data  bases  or  files  where  the 
appropriate  data  may  be  found,  but  it  might  also  be  a location  in 
a filing  cabinet  in  the  office,  or  it  may  be  the  name  and  phone 
number  of  the  resident  (human)  expert  who  is  quite  likely  to  be 
the  oest  available  knowledge  source  for  certain  problems.  with 
most  present-day  data  managers,  this  association  function  is  per- 
formed by  humans  who  quite  frequently  are  unavailable  at  the  time 
the  question  arises.  Granted,  some  systems  may  maintain  a file 
of  key  personnel,  but  the  knowledge  of  why  those  people  are  key 
or  what  questions  they  are  likely  to  be  able  to  answer  is  gen- 
erally retained  in  the  users'  heads  (where  it  can  be  hard  to 
access  ) . 

0.1.2  USER  INTERFACES 

Just  as  there  is  the  need  in  large-scale  systems  tor  several 
knowledge  resource  tools,  each  serving  a different  knowledge 
function,  so,  too,  is  there  a need  tor  several  user  interfaces 
which  provide  specific  knowledge-based  capabilities  and  which 
permit  knowledge  applications  views  of  the  data  to  the  end-users, 
we  believe  that  it  is  both  desirable  and  necessary  to  distinguish 
among  the  human  users  of  any  Information  system  in  terms  of  their 
needs,  desires,  capabilities,  motivations,  and  especially  in 
terms  of  the  needs  dictated  by  the  particular  application 
knowledge  of  tne  user.  In  this  regard,  there  is  the  need  to 
develop  user  Interfaces  not  only  with  an  eye  on  what  it  might 
take  to  train  the  potential  users,  but  also  with  an  appreciation 
tor  preserving  the  view  of  data  which  is  natural  to  them  and  to 
tneir  application.  This  is  really  nothing  more  than  a recogni- 
tion of  the  tact  that  in  today's  world,  and  in  the  world  of  the 
foreseeable  future,  the  main  costs  in  an  Information  system  will 
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be  for  people  and  the  creation  and  maintenance  of  their  Knowledge 
oases,  not  for  machines  to  process  them.  With  this  fact  in  mind, 
we  Infer  tnat  tnere  must  be  a rich  variety  of  user  interfaces 
available  to  support  the  wide  variety  of  humans  who  are  expected 
to  use  the  Knowledge  resource.  Figure  6-4  shows  eleven  different 
user  interfaces  which  we  feel  are  important  for  the  proper  func- 
tioning of  a department.  This  list  is  not  necessarily  complete, 
depending  on  the  user  population  and  purpose  (indeed,  James  Mar- 
tin ( 2 9 J has  identified  some  eighteen  distinct  user  interfaces). 
Further  details  about  user  interfaces  can  be  obtained  by  refer- 
ring to  Martin's  worK,  and  the  reader  is  encouraged  to  do  so. 

No  one  user  interface  is  liKely  to  be  adequate  for  all  users 
or  all  Knowledge  areas  within  the  department.  Each  provides  a 
specific  view  to  accomplish  a specific  function.  Neither  must 
any  one  system  provide  all  possible  user  interfaces.  Only  those 
interfaces  which  fulfill  a real  need  should  be  included  in  a 
given  system  being  developed  for  a project.  For  example,  in  a 
project  where  users  employ  algorithmic  Knowledge  predominately, 
the  users  might  be  very  content  with  a forms  or  a menu  type  of 
interface.  On  the  other  hand,  a user  who  employs  heuristic 
Knowledge  heavily  would  undoubtedly  chafe  under  such  restrictive 
interfaces.  What  is  recommended  is  that  a selection  of  user 
interfaces  (standardized  throughout  the  department)  be  available 
tor  system  designers  to  picK  and  choose  from  as  needed. 
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USER  INTERFACE 

* Transaction 

* Menu 

* Forms 

* Graphical 

* Dialogues 

* Natural  Language 
Subset 

* Query  Language 

* Relational 

* Programmatic 

* Navigational 

* Text  Editor 


DESCRIPTION 

- Rapid  response;  terse  commands;  intended 
for  all-day  repetitive  use;  limited  view 
of  the  Knowledge  resource. 

- Commands  selected  by  the  users  from  a 
list  presented  dynamically;  very  simple; 
primarily  for  casual  users. 

- Data  entry  and  retrieval  is  accomplished 
via  predescribed  forms;  tor  casual  and 
dedicated  users  both. 

- (a)  Information  as  charts,  graphs,  etc.; 
(b)  Information  as  dynamic  animation; 
easy  to  interpret;  information-rich. 

- User-specific,  interactive  question/ans- 
wer mode  initiated  by  either  the  system 
or  the  user. 

- A limited-context  capability  for  speci- 
fying commands  in  a subset  of  natural 
language  (e.g.,  English). 

- A formal  language  for  specifying  re- 
quests explicitly. 

- A more  powerful  form  of  a query  language 
which  allows  dynamic  restructuring  of 
data  bases  as  needed. 

- Extension  of  existing  formal  computer 
programming  languages  to  accommodate 
data  management  functions. 

- (a)  Access-path  dependent  traversal  of 
a data  base; 

(b)  Access-path  independent  traversal 
of  the  Knowledge  resource. 

- To  create  and  maintain  local  files  of 
private  interest  (such  as  notes,  debugs, 
and  memos)  as  well  as  textual  documents. 

USER  INTERFACES 

Figure  6-4 
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Figure  6-6  Indicates  tne  authors'  feelings  about  the  rela- 
tionship of  the  six  user  functional  groups  to  the  eleven  user 
interfaces  discussed  in  this  section.  There  will  be  considerable 
overlap  of  individuals  within  the  groups;  consequently,  it  is  not 
possLble  to  limit  the  user  interfaces  to  only  a subset  of  the 
groups  (or  vice  versa).  However,  in  general,  the  primary 
expected  usage  is  that  shown  in  the  figure. 

It  is  evident  from  Figure  6-6  that  Analysts  and  Information 
Specialists  have  need  for  very  similar  user  interfaces.  This  is 
to  be  expected  since  their  functions  are  similar.  An  Information 
Specialist  is  really  just  an  Analyst  with  a concentrated  speci- 
alty in  the  information  tools  available  with  the  Knowledge 
resource.  It  also  appears  from  Figure  6-6  that  some  job  skills 
(Analysts  and  Information  Specialists,  in  particular)  require  a 
large  number  of  user  interfaces.  It  must  be  pointed  out  that 
while  the  functional  groups  may  need  all  of  the  interfaces 
listed,  no  single  person  is  expected  to  need  to  use  more  than  a 
few.  Even  so,  it  might  be  useful  to  develop  a single  higher- 
level  user  interface  from  which  each  of  the  interfaces  in  Figure 
6-4  can  be  accessed  in  a smooth  consistent  fashion.  This  high- 
level  interface  may  or  may  not  be  identical  for  all  functional 
user  types.  Such  an  interface  is  another  potential  application 
of  a Knowledge-based  system  (see,  tor  example,  Section  5.1.6  on 
RITA's  high-level  interface  to  the  ARPAnet). 
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6.2  STRUCTURAL  VIEW 

The  Structural  View  provides  a way  ot  looking  at  the  organi- 
zational functions  which  will  need  to  be  performed  by  a depart- 
ment which  is  seeking  to  manage  its  knowledge  as  a resource, 
Tnis  Structural  View  is  based  on  tne  architectural  model  that  was 
recently  presented  in  an  American  National  Standards  Institute 
( ansi ) /X3/SPARC  study  group  report  on  data  management  systems 
130] . Their  architectural  model  is  designed  to  support  the 
current  and  future  requirements  of  large  complex  organizations 
and  appears  to  provide  parts  of  what  would  be  needed  to  support  a 
knowledge  resource. 

A short  description  which  deals  with  the  macro-level  details 
of  the  architecture  is  followed  by  a chart  which  serves  to  cap- 
ture the  flavor  of  the  architecture.  Additional  details  may  be 
obtained  by  referring  to  tne  source  document  referenced  in  the 
paragraon  above,  and  the  reader  is  encouraged  to  do  so.  In 
essence,  the  ANSI  architecture  is  based  on  tne  notion  that  there 
are  three  realms  of  information  that  are  of  interest  to  an  organ- 
ization, namely:  tne  real  world,  ideas  about  the  real  world  that 
exist  in  the  minds  of  its  people,  and  the  symbols  on  some  storage 
medium  that  represent  these  ideas.  The  ANSI  group  believes  that 
information  in  each  of  these  realms  has  properties  that  differ 
subtly  and  significantly  from  those  of  other  realms.  These  pro- 
perties and  their  differences  are  used  to  form  the  basis  for 
their  information  model. 

The  ANSI  group  postulated  three  models  of  the  information 
world  of  an  enterprise  and  designed  an  architecture  to  support 
the  three  realms  of  interest.  The  three  realms  are  identified 
as : 

External  - a simplified  model  of  the  real  world 
as  seen  by  an  application  or  family 
of  applications 

Conceptual  - a limited  model  of  the  real  world 
as  viewed  by  the  entire  enterprise 

Internal  - a model  depicting  the  data  that  re- 
sides in  the  physica-ir-storage  medium. 

Each  of  tnese  realms  consists  of  a data  model  and  a schema 
describing  that  model.  The  objects  of  interest  in  the  real  world 
are  called  entities,  and  the  facts  ot  interest  about  the  entities 
are  called  attributes.  These  concepts  are  consistent  with  our 
use  of  tne  terms  as  expressed  earlier  in  this  paper. 

The  external  model  is  a collection  of  objects  that  represent 
the  entities  and  attributes  of  interest  to  a specific  application 
or  family  of  applications.  Each  external  model  is  described  by 
an  external  schema.  It  follows  that  there  will  be  as  many  exter- 
nal schemas  as  there  are  applications  which  use  the  data 
resource.  Tne  humans  who  are  responsible  for  creating  and 
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maintaining  the  external  schemas  and  for  providing  the  interfaces 
to  the  end-users  of  the  data  resource  are  called  Application 
Administrators  C A A ) - 

The  conceptual  model  is  a collection  of  the  objects  that 
represent  the  total  entitles  and  attributes  of  the  enterprise, 
(we  shall  expand  this  definition  in  Section  8 to  include  the 
Knowledge  of  an  enterprise.)  The  conceptual  schema  is  created  and 
maintained  oy  a human  called  the  Enterprise  Administrator  (EA). 
The  main  focus  of  this  schema  is  on  the  organization's  total 
Knowledge  resource.  For  obvious  reasons  there  can  be  only  a sin- 
gle conceptual  schema  in  the  department.  It  serves  as  the  infor- 
mation model  of  tne  total  organization. 

The  internal  model  is  a collection  of  objects  containing  the 
stored  data  that  represent  the  external  and  conceptual  models. 
Tne  internal  model  is  described  by  an  internal  schema,  and  for 
consistency,  there  must  be  only  one  internal  schema  tor  each  phy- 
sical data  base.  Each  internal  schema  is  created  and  managed  by 
a human  called  a Data  Base  Administrator  (DBA)  who  is  responsible 
tor  providing  the  interface  to  the  hardware  and  software  of  the 
information  system.  Thus,  the  DBA  must  have  a heavily  technical 
orientation. 

A macro  view  of  the  overall  model  is  presented  in  Figure  b-b. 
As  noted  previously,  the  ANSI  group  identified  different  orienta- 
tions for  the  conceptual,  the  external,  and  the  internal  parts  of 
the  overall  model.  They  have  correspondingly  identified  three 
distinct  human  roles  whicn  reflect  the  different  orientations. 
The  Enterorise  Administrator  deals  with  a high-level  macro  view 
of  the  enterprise's  Knowledge  resource.  The  Applications 
Administrator  deals  with  end  users  and  their  localized  view  of 
the  Knowledge  resource.  The  Data  Base  Administrator  deals  with 
the  highly  technical  hardware  and  software  functions  of  the  data 
base  management  systems  and  thus  holds  a physical  view  of  the 
Knowledge  resource. 

In  one  sense,  the  conceptual  model  of  the  Enterprise  Adminis- 
trator can  be  tnought  of  as  a top  management  or  corporate  view  of 
the  entire  Knowledge  resource  from  the  standpoint  of  the 
Knowledge  that  is  being  produced  and  maintained  and  the  data 
wnicn  the  enterprise  needs  to  acquire  in  order  to  support  its 
Knowledge  applications.  The  EA  seeKs  to  optimize  the  acquisition 
and  preservation  of  Knowledge  across  the  entire  organization  and 
must  therefore  be  prepared  to  deal  with  all  of  the  Knowledge  con- 
texts of  the  department.  The  external  model  of  the  Applications 
Admini  strator  focuses  attention  on  the  development  and  use  of  the 
application  Knowledge  bases.  The  AA  must  be  aware  of  the  data 
oases  and  the  metadata  oases  which  the  Knowledge  applications 
need  to  access  in  order  to  operate.  This  fact  causes  the  AA  to 
use  a mission  or  application  context  when  viewing  the  Knowledge 
resource.  The  internal  model  of  the  Data  Base  Administrator 
centers  on  the  data  bases  and  metadata  bases  and  on  the  technical 
details  of  providing  that  data  to  users  rapidly  and  cheaply,  and 
this  results  in  a computer  context  orientation  for  the  DBA.  In 
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actual  practice,  tne  division  of  interests  will  not  be  nearly  so 
clear  cut,  and  tne  department  will  require  cooperation  from  all 
tnree  administrat ive  functions  as  well  as  all  three  knowledge 
context  areas. 

The  Structural  View  presented  here  will  be  used  in  tne  sec- 
tions wnich  follow  to  suggest  the  basic  functions  which  we 
believe  will  need  to  be  performed  if  an  organization  is  to 
create,  build,  and  maintain  a knowledge  resource.  Support  for 
tne  functions  identified  here  will  be  contained  in  the  logical 
system  design  of  Section  8.  The  Structural  View  will  also  be 
used  in  Appendix-1  to  identify  problem  areas  and  research  topics 
whicn  are  relevant  to  the  development  of  a knowledge  resource. 
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6.2. 1 KNOWLEDGE  RESOURCE  FUNCTIONS 

Some  oasic  functions  will  need  to  be  carried  out  if  a depart- 
ment is  to  implement  and  maintain  a knowledge  resource.  We  nave 
designed  a theoretical  structure  which  contains  all  of  the 
appropriate  functions  in  a single  centralized  organizat ion . This 
is  not  meant  to  imply  that  centralization  of  the  functions  is  the 
only  possible  solution  or  even  the  best  solution.  A centralized 
approach  is  presented  here  as  a convenient  way  to  identify  and 
discuss  the  functions  at  one  time.  The  actual  implementation  of 
an  organizational  structure  for  managing  the  knowledge  resource 
is  best  left  to  the  discretion  of  the  individual  departments. 
Figure  6-7  snows  a possible  break-down  of  tasks  by  function 
within  the  theoretical  office  of  Enterprise  Administration.  The 
key  executive  officer  in  such  an  organizational  structure  would 
be  an  Enterprise  Administrator.  An  important  part  of  an  EA's 
responsibility  would  be  the  direction  and  control  of  the 
knowledge  resource  center  which  acts  as  a nerve  center  to  coordi- 
nate the  knowledge  activities  of  the  department  (see  Appendix-1). 
Policy,  Security,  and  Standards  are  important  functions  which  are 
also  represented  in  the  diagram.  Control  and  coordination  of 
these  efforts  are  needed  to  insure  that  proper  enterprise  goals 
are  established  and  met.  The  function  of  the  External  Informa- 
tion Sources  group  is  to  integrate  into  the  knowledge  resource 
factual  knowledge  which  is  primarily  textual  such  as  documents, 
periodicals,  newspapers,  books,  reports,  and  other  library 
materials.  These  sources  may  or  may  not  be  automated.  Knowledge 
Resource  Tecnnology  Assessment  incorporates  the  functions  of 
tracking  research  efforts  in  the  areas  of  hardware  and  software 
relevant  to  knowledge  resource  tools  and  assessing  the  utility 
and  impact  of  such  new  technology  on  the  organization.  The 
technical  role  of  the  Data  Base  Administrator  has  been  described 
earlier  in  the  paper.  Tne  DBA's  are  located  under  the  control  of 
tne  EA  in  order  to  insure  cooperation  among  the  various  DBA's 
toward  tne  common  goals  of  the  department.  Note  that  there  may 
need  to  be  several  DBA's,  and  some  hierarchical  structure  may  be 
desirable.  Tne  Applications  Administrators  are  shown  in  the 
diagram  to  indicate  the  need  for  close  coordination  with  the  EA. 
As  stated  earlier,  the  Aa's  primary  function  is  to  support  and 
represent  the  users'  point  of  view.  In  this  regard,  the  AA's 
probably  should  not  be  under  tne  direct  control  of  the  EA,  but 
ratner,  snould  belong  to  the  various  user  organizations  (hence 
tne  dotted  line). 
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Tae  joo  of  an  EA  is  extremely  complex  and  diverse.  No  clear- 
cut  list  of  desired  skills  (political,  managerial,  or  technical) 
has  oeen  developed  at  present.  It  is  entirely  possible  that  a 
department  may  need  different  mixes  of  skills  and  functions  as 
they  move  from  one  phase  of  creating  a knowledge  resource  to 
anotner.  At  one  point,  an  organization  may  feel  the  need  for  an 
office  of  knowledge  resource  administration  and  at  some  other 
point  they  may  not  need  a knowledge  resource  administrator.  It 
seems  clear,  however,  that  the  persons  or  organizations  which 
will  oe  responsible  for  creating  the  knowledge  resource  will  need 
appropriate  access  to  upper  management.  In  any  case,  the  exact 
placement  of  the  EA  function  cannot  be  determined  before  the  ini- 
tial decision  to  create  a knowledge  resource  is  made.  For 
instance,  if  mission  knowledge  is  identified  as  the  target  of  a 
knowledge  resource  program,  then  perhaps  mission  managers  should 
organize  and  control  the  function  which  we  have  identified.  If, 
nowever,  knowledge  relative  to  all  of  the  disciplines  of  the 
organization  is  the  target,  then  different  mechanisms  for  organ- 
izing and  controlling  these  functions  would  seem  to  be  needed. 
Policy  and  organizational  decisions  such  as  these  are  the  pro- 
vince of  tne  Secretary  and  the  management  council  of  the  depart- 
ment . 
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6.3  PHYSICAL  VIEW 

rne  Physical  View  ot  an  enterprise  not  only  reflects  the 
current  hardware/software  environment  of  the  organization,  but 
also  encompasses  the  state-of-the-art  components  which  the  enter- 
prise needs  to  acquire  or  develop.  The  Physical  View  is,  of 
course,  most  relevant  to  the  tools  and  support  context  of  the 
department.  In  many  departments,  the  knowledge  functions 
described  in  the  Functional  View  might  be  performed  on  different 
computer  systems  (from  a mix  of  vendors)  with  different  file  sys- 
tems, tile  management  systems,  data  base  management  systems,  and 
knowledge  base  management  software.  In  addition,  several  mass 
archival  storage  devices  could  be  connected  to  individual  comput- 
ers or  to  some  set  of  machines  (e.g.,  IBM  3850  or  AMPEX  TBM ) . 
There  have  been  tew  limitations  on  computer  type,  terminal  type, 
software  packages,  or  mass  storage  devices  which  a department  may 
employ.  The  resultant  environment  may  present  formidable  bar- 
riers to  the  creation  of  a knowledge  resource  from  either  the 
computer  context  or  from  the  other  contexts  which  employ  the  com- 
ponents of  the  Physical  View.  An  orderly  Physical  view  is  neces- 
sary for  tne  proper  selection  of  hardware  and  software  components 
to  manage  the  knowledge  resource  optimally.  A decision  to  choose 
a standard  terminal  subsystem,  for  example,  would  oe  a signifi- 
cant move  toward  an  orderly  Physical  View.  Figure  6-8  shows  part 
ot  tne  potential  configuration  of  a network  with  some  of  the 
variety  of  data  management  software  supported  by  the  machines. 

I’he  philosophy  of  treating  knowledge  as  a departmental 
resource  assumes  that  there  is  considerable  need  tor  sharing  of 
data,  information,  and  knowledge  among  the  various  divisions  of 
the  enterprise.  Today's  technology  in  computer  networking 
(namely  that  employed  on  the  ARPANET  network)  can  provide  the 
communications  links  for  sharing  data  among  several  machines. 
However,  this  technology  is  severely  lackinq  in  providing  an  ade- 
quate vehicle  for  communicating  the  logical  structures  of  and  the 
relationships  among  the  data  involved,  i.e.,  the  factual 
knowledge.  Things  are  even  less  developed  in  the  area  of  .pro- 
cedural knowledge  sharing.  Strictly  speaking,  data  shiring 
implies  the  need  tor  similar  processing  capabilities  at  each  node 
in  tne  network,  and  hence,  duplication  of  effort.  The  same  data 
is  available  tor  processing  by  several  different  nodes,  but  the 
results  ot  one  processing  activity  are  generally  not  available  to 
another.  The  various  systems  merely  process  the  same  data  in 
somewhat  different  fashions  in  order  to  derive  different  informa- 
tion pertinent  to  their  own  local  activity. 
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The  goal  of  a department  should  not  be  data  sharinq,  but 
rather,  Knowledge  sharing,  where  each  process  in  the  system  per- 
forms some  function  on  the  data,  derives  some  useful  Knowledge 
from  it,  and  then  makes  this  Knowledge  available  to  subsequent 
processes  tor  additional  Knowledge  production.  Each  step  in  the 
series  not  only  puts  the  data  to  some  local  use,  but  adds  value 
to  the  data  by  bringing  together  in  new  relationships  some  previ- 
ously unassociated  data  items,  thus  enhancing  the  metadata  base. 
In  addition,  new  procedural  Knowledge  might  also  be  developed  and 
made  available.  In  this  fashion,  the  value  of  the  entire 
Knowledge  resource  is  enhanced  for  all  members  of  the  organiza- 
tion. 

In  the  real  world  imposed  by  the  Physical  View,  the  sharing 
of  Knowledge  is  not  an  easy  tasK.  Great  disparities  exist  among 
the  hardware  and  software  components,  and  the  technology  neces- 
sary to  overcome  these  differences  can  indeed  be  complex.  Of 
utmost  importance  (but,  indeed,  difficult)  is  imparting  to  humans 
or  to  other  systems  the  representation  of  the  logical  structure 
of  the  data  bases,  i.e.,  the  tactual  Knowledge  which  they  con- 
tain. MaKing  procedural  or  judgmental  Knowledge  available  will 
be  even  more  of  a challenge.  The  automatic  communication  of  the 
meaning  of  a data  base  oi  of  a Knowledge  base  appears  to  be 
beyond  the  state-ot-the-ar t today,  and  yet  this  is  precisely  what 
is  needed  before  we  can  truly  claim  to  have  a Knowledge  resource 
shared  among  a number  of  machines. 

There  are  several  approaches  which  we  may  taKe  in  attempting 
to  alleviate  some  of  the  technical  problems  of  data  sharing  in  a 
computer  networK  1313.  The  applicability  of  these  solutions  to 
the  broader  problem  of  Knowledge-sharing  has  not  yet  been 
explored.  Four  of  these  approaches  are  listed  below, 

1.  Standardizat ion  - an  organization  may  decree  that  identical 
hardware  and/or  software  will  be  used  throughout  the  networK 
thereby  removing  the  disparity  among  systems.  Such  an  approach 
may  oe  Impractical  or  imprudent  for  a variety  of  reasons  includ- 
ing economic,  political,  legal,  or  technical  factors.  The  impact 
of  standardizat ion  on  existing  equipment  and  programs  in  a 
department  might  be  so  enormous  as  to  rule  it  out  as  a viable 
solution.  An  extensive  cost/evaluation  study  would  be  required. 

z.  Centralization  - a department  may  deem  it  appropriate  to 
require  that  all  Knowledge  processing  and  access  be  performed  at 
a central  site  on  a single  or  homogeneous  set  of  machines 
intended  solely  tor  that  function.  The  fact  that  centralization 
can  imply  a single  point  of  failure  tor  the  networK  together  with 
the  problems  of  communication  speeds  for  large  volumes  of  data 
rnaKe  cent r a 1 i zat i on  less  than  ideal.  A modification  of  the 
approach  is  Distributed  Centr a l izat ion  (e.g,,  via  a bacK-end  data 
management  machine  [32,33, 34J)  where  identical  hardware/software 
is  distriouted  throughout  the  networK  to  perform  data  management 
functions  exclusively.  This  approach  is  intended  to  improve  per- 
formance, increase  reliability,  and  provide  locality  of  data  to 
the  processes  which  use  it. 
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i . Transformation  - a third  alternative  is  the  automatic 
trans t ormat ion  of  discrete  data  structures  from  one  system  to 
another  throughout  tne  network.  Assuming  such  a transformation 
(including  subsequent  communications)  could  be  performed  rapidly 
enough  to  be  of  use,  the  resultant  duplication  of  data  and  the 
inherent  problems  of  keeping  duplicate  data  bases  in  synchrony 
make  transformation  an  unlikely  solution  for  Knowledge  sharing, 
iet,  there  is  still  the  very  real  problem  of  system  migration 
from  one  generation  of  hardware  or  software  to  another,  and 
t rans f ormat ion  technology  can  greatly  assist  in  this  costly  and 
time-consuming  process. 

4.  Translation  - the  fourth  alternative  tor  a department  is  to 
construct  a translation  mecnanism  whereby  requests  for  informa- 
tion in  one  system  can  be  automatically  translated  into  requests 
comprehensible  to  other  systems  as  appropriate.  The  translation 
mechanism  may  be  eitner  centralized  at  one  local  site  or  it  may 
oe  distributed  throughout  the  network,  possibly  in  tne  form  of 
front-end  machines.  In  eitner  case,  an  Important  theoretical 
problem  still  exists  concerning  whether  or  not  it  is  even  possi- 
ble to  translate  complex  requests  for  information  into  terms 
wnicn  a simple-structured  data  management  system  can  understand. 
In  addition  to  this,  there  is  also  the  problem  of  the  unres- 
trained propagation  of  data  management  systems  and  tne  constant 
need  for  additional  translators  throughout  the  life  of  the  net- 
work. 


Distributed  centralization  (back-ends)  and  distributed  trans- 
lation (front-ends)  appear  to  be  the  two  most  technologically 
sound  approaches.  Their  difference  is  one  of  emphasis:  whether 
all  data  management  can  and  should  be  performed  by  a single  kind 
of  system  so  that  requests  tor  knowledqe  from  various  nodes  in 
the  network  need  not  be  translated,  or  whether  the  advantages  of 
eacn  unique  data  management  system  are  sufficient  to  warrant 
tneir  retention  at  the  cost  of  continually  translating  requests 
and  responses.  Other  approaches  are  undoubtedly  possible, 
including  hybrids  of  the  four  mentioned  above.  Each  department 
will  have  to  decide  tne  approach  most  appropriate  to  its  own 
unique  set  of  circumstances. 

Regardless  of  the  approach  taken  by  a department,  there 
remain  many  other  problems  in  attempting  to  share  knowledge  in  a 
computer  network.  There  are  proDlems  of  distribution,  duplica- 
tion, and  synchronization  among  data  bases.  There  are  problems 
of  concurrent  updating,  network  locking  strategies,  and  multi- 
processor deadlocks.  Tnere  are  problems  of  locating  all  per- 
tinent data  from  a number  of  sources,  data  base  navigation 
through  unknown  structures,  and  the  need  for  a network-oriented 
diet ionary/di rectory . Finally,  there  is  the  unique  security 
problem  of  the  vu lne r aD i 1 i t y and  sensitivity  of  the  network 
directory  and  the  navigational  facility.  Therein  lies  the  key  to 
tne  organization  of  knowledge  of  the  entire  department.  Prior  to 
tne  establishment  of  such  a facility,  the  knowledge  relevant  to 
data  base  organization  was  distributed  throughout  the  various 
processing  centers.  Access  to  one  did  not  provide  access  to  or 
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Knowledge  about  the  functioning  of  any  other.  Security  was 
accomplished  by  obfuscation.  with  this  facility,  everything 
which  the  department  does  with  data  is  described  in  a neat  and 
orderly  fashion.  Such  Prized  knowledge  makes  the  network  direc- 
tory and  its  associated  features  a prime  target  for  attack. 

b.4  RELATIONSHIP  OF  I HE  THREE  VIEWS 

Given  that  the  Functional,  Structural,  and  Physical  Views  are 
all  views  of  a knowledge  resource  within  an  enterprise,  it  is 
interesting  to  determine  how  they  correspond  to  each  other  and 
where  they  overlap.  The  Physical  View  considers  the  actual 
hardware  and  software  employed  by  a department  to  carry  out  the 
functions  necessary  to  its  mission.  This  View  identities  the 
actual  tile  systems,  file  management  systems,  and  data  base 
management  systems  of  the  Functional  View  which  are  used  to  store 
and  maintain  the  data  throughout  the  department.  The  Physical 
View  lists  the  tools  which  are  available  to  the  various  people 
identified  in  the  structural  View  to  enable  them  to  do  their 
jobs. 


The  structural  View  is  related  to  the  Functional  View  as  fol- 
lows. The  conceptual  model  is  concerned  with  overall  organiza- 
tional productivity  and  the  flow  of  data  from  process  to  process 
(node  to  node)  as  it  moves  about  in  the  system  (where  the  system 
may  oe  a single  computer  or  an  entire  network).  Consequently, 
the  conceptual  model  addresses  the  areas  of  interaction  among 
processes.  The  internal  model  deals  with  the  efficient  perfor- 
mance and  maintenance  of  individual  processes  within  a node. 
Hence,  the  internal  model  gives  a microscopic  look  at  the  nodes 
of  the  system.  The  external  model  is  the  user's  view  of  the  sys- 
tem and  hence  is  concerned  with  the  interfaces  (access  languages, 
application  programs,  etc.)  which  access  the  various  nodes. 

From  the  external  point  of  view,  the  users  would  like  to  see 
a uniform  front,  i.e.,  standard  interfaces.  They  want  interfaces 
which  facilitate  their  working  with  a particular  knowledge  base 
regardless  of  what  it  is.  They  do  not,  nor  should  they,  care 
about  the  underlying  machinations  required  to  supply  them  with 
tne  data  they  need  to  support  their  knowledge  applications. 
While  the  users  are  aware  that  requests  for  service  cost  money  in 
terms  of  hardware  and  software  resources  expended,  it  matters 
little  to  them  whether  the  request  is  translated  or  transformed 
or  whether  it  is  processed  locally  or  remotely.  The  main  costs 
which  the  users  see  are  the  human  costs  involved  in  their  use  of 
the  system.  Users  tend  to  get  very  upset,  and  rightfully  so, 
with  systems  where  trade-offs  in  cost  have  been  made  in  favor  of 
hardware  and  software  at  the  expense  of  Increased  human  costs  and 
increased  difficulty  in  developing  their  knowledge  applications. 
Inadequate  human/machine  interfaces  have  been  provided  in  the 
past  which  have  been  designed  to  favor  machine  efficiency  over 
the  efficiency  of  the  human  users.  The  things  that  are  important 
to  tne  users  are  the  validity  of  the  response  and  the  basis  for 
it,  tne  timeliness  of  the  data,  the  speed  with  which  the  request 
is  processed,  and  the  ease  with  wnich  they  can  obtain  what  they 
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need  from  the  system.  In  addition,  the  system  must  be  able  to 
accommodate  the  changing  mission  environments  with  which  the 
users  must  deal.  Users  Know,  only  too  well,  that  they  are  worK- 
ing  on  problems  wnich  Keep  changing.  Computerized  systems  must 
be  flexible  enough  to  adjust  to  the  continual  changing  require- 
ments and  specifications  which  are  common  and  necessary.  In 
seeKing  to  develop  a Knowledge  resource  an  organization  must 
recognize  these  important  aspects  and  organize  their  system 
accordingly.  Failure  to  do  so  will  result  in  the  overall  failure 
of  a department's  effort  to  optimize  the  use  of  all  of  its 
resources . 

From  the  internal  point  of  view,  a Data  Base  Administrator 
would  liKe  to  see  a consistent  and  efficient  system,  Stanaardi- 
zation  of  tne  system  can  maKe  the  job  easier  in  terms  of  training 
and  maintenance  efforts,  but  standardization  can  also  have  a 
negative  effect  on  performance.  The  DBA  is  caught  in  the  unenvi- 
able position  of  having  to  provide  adequate  service  to  the  users 
while  adhering  to  enterprise  policies  based  on  global  optimiza- 
tion . 


From  the  conceptual  point  of  view,  an  Enterprise  Administra- 
tor should  be  worried  about  maKing  the  entire  thing  worK  together 
for  tne  benefit  of  the  department  as  a whole.  An  EA  might  need 
to  step  on  a few  toes  in  the  struggle,  and  he  or  she  might  have 
to  pursuade  the  users  to  exercise  a proper  amount  of  restraint  to 
ensure  that  global  priorities  are  met.  The  EA  should  be  respon- 
sible tor  coordinating  the  various  DBA's  to  ensure  that  ample 
facilities  are  present  to  allow  Knowledge  sharing  to  taKe  place. 

The  three  Views  (Functional,  Structural, and  Physical)  provide 
three  ways  to  view  a Knowledge  resource  in  a large  complex  enter- 
prise. They  are  each  related  to  the  others  in  that  they  are 
modeling  the  same  process,  but  they  differ  in  their  emphasis  and 
point  of  view.  Each  View  provides  a useful  way  of  looKing  at 
certain  subsets  of  the  overall  system  depending  on  the  interest 
of  the  observer. 
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7.  STEPS  TOWARD  REALIZING  A DEPARTMENTAL  KNOWLEDGE  RESOURCE 

Once  a department  reacnes  tne  conclusion  that  Knowledge  is, 
indeed,  a valuable  resource  and  one  which  should  be  created  and 
developed,  what  could  a department  do  to  allow  this  to  come 
about?  There  are  many  problems,  both  technical  and  managerial, 
whicn  an  organization  should  expect  to  face  in  moving  from  their 
current  position  to  one  where  Knowledge  is  a resource.  in  the 
following  sections  we  present  some  technical  and  managerial 
issues  which  will  require  solutions  before  an  organization  can 
create  an  effective  Knowledge  resource. 

•7.1  TOP  MANAGEMENT  COMMITMENT 

First  on  tne  list  of  things  to  do  is  to  obtain  the  written 
and  public  commitment  of  top  management  to  explore  the 
knowiedge-as-a-resource  philosophy.  As  we  stressed  earlier, 
failure  to  obtain  such  a firm  commitment  at  the  outset  so  under- 
mines the  concept  as  to  almost  guarantee  the  failure  of  an  imple- 
mentation. Before  a knowledge  resource  policy  can  be  implemented 
management  must  be  convinced  of  the  appropriateness  and  desira- 
bility of  recognizing  Knowledge  as  an  organizational  resource. 
This  is  not  a small  task  to  be  crushed  over  hurriedly  in  a one- 
hour  briefing.  Top  management  must  understand  the  concept  of  a 
Knowledge  resource  and  they  must  be  convinced  that  it  is  both 
viable  and  beneficial,  i.e.,  that  in  the  final  analysis  it  will 
save  money  and/or  increase  capabilities.  This  commitment  should 
be  preceded  by  a study  which  includes  a statement  of  the 
organization's  goals  and  objectives  and  an  assessment  of  the 
current  state  of  affairs  in  data  management  and  Knowledge-based 
systems  technology.  In  addition,  some  preliminary  Plans  and  cost' 
analysis  for  the  next  several  phases  of  the  implementation  will 
De  required  before  management  can  make  an  Informed  decision.  The 
preliminary  plan  must  be  flexible  enough  to  allow  organizational 
change  as  the  organization  proceeds  toward  the  creation  of  an 
effective  Knowledge  resource.  The  plan,  in  effect,  could  serve 
as  a basic  Knowledge  resource  charter  for  the  department  by  out- 
lining what  is  to  be  accomplished  without  specifying  how  is  to 
be  done.  This  latter  point  is  most  important  since  the  impact  of 
this  philosophy  will  ripple  throughout  the  department.  Freezing 
the  steps  to  a knowledge  resource  too  early  may  force  a pace  that 
is  either  too  rapid  or  not  fast  enough.  Organizational  learning 
must  be  built  into  the  plan,  and  its  pace  will  be  difficult  to 
predict  accurately  (at  least  in  the  early  staaes). 

7.2  PUBLIC  RELATIONS 

Once  top  management  has  been  convinced  of  the  important 
ootential  ot  viewing  Knowledge  as  a departmental  resource,  the 
job  remains  for  someone  to  spread  the  word  among  the  various 
organizations  within  the  department,  A base  of  support  in  the 
entire  department  should  be  built  by  informing  pertinent  person- 
nel ot  tne  goals  of  the  new  approach  and  by  soliciting  their 
assistance.  During  this  phase  the  groundwork  is  being  laid  for 
unification  and  smoother  working  relationships  in  the  years 
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ahead . 

7.3  MODELS  OF  ACTUAL  CONDITIONS 

If  a department  decides  that  an  EA  and  associated  staff  are 
needed,  then  they  can  be  assigned  the  responsibility  for  develop- 
ing the  Knowledge  resource.  Otherwise,  the  responsibility  will 
need  to  be  assigned  to  some  existing  organizations.  In  any  case, 
one  of  tne  first  things  to  be  done  is  to  identify  and  classify  as 
much  of  the  organization's  Knowledge  Call  types)  as  possible. 
Tnis  will  help  the  department  understand  what  it  is  that  will  be 
in  the  resource.  Another  thing  to  be  done  is  to  build  a set  of 
models  of  the  Functional,  Physical,  and  Structural  Views  of  the 
department  (see  Section  b).  These  views  should  not  be  limited  to 
a description  of  the  current  state  of  affairs  but  should  also 
include  an  assessment  of  where  the  department  could  be,  should 
be,  and  prooaDly  will  pe  in  tne  next  5 years.  These  models  are 
very  important  to  the  organization's  Knowledge  resource  planning, 
tor  they  carry  in  them  all  the  work  that  needs  to  be  done  if  the 
department  is  to  move  from  its  current  state  to  one  wherein 
Knowledge  can  be  an  effective  resource  of  the  department. 

7.4  JOINT  FUNDING  OF  RESEARCH 

A department  should  not  try  to  "go  it  alone"  in  building  a 
Knowledge  resource.  It  is  doubtful  that  any  single  enterprise 
nas  sufficient  money  and  expertise  to  successfully  complete  this 
endeavor  alone.  Instead,  they  should  seeK  out  relevant  commit- 
tees to  join  and  support  such  as  those  of  ANSI,  CODASYL  (Commit- 
tee on  Data  System  Languages),  and  the  GUIDE  and  SHARE  groups  of 
users  of  IBM  equipment.  A department  needs  to  participate  in 
these  organizations  both  to  gain  Knowledge  and  to  nave  some 
impact  on  the  direction  of  these  efforts.  Key  individuals  and 
other  organizations  with  similar  problems  should  be  identified 
and  contacts  established  so  that  experiences  can  be  Shared  and, 
where  possible,  resources  can  be  pooled.  Conferences  and  meet- 
ings are  an  excellent  source  of  such  contacts.  Also  various 
research  efforts  should  be  identified  (see  Section  7.5)  and  clas- 
sified as  to  whether  they  should  be  funded  by  the  department  or 
merely  tracxed.  The  lucrative  possibilities  of  joint  funding  of 
research  and  development  in  areas  of  mutual  interest  must  not  be 
overlooKed. 

7 . b KEY  RESEARCH  TOPICS  AND  PROBLEM  AREAS 

In  Appenaix-l  we  outline  some  of  the  Key  issues  which  are 
relevant  to  an  organization's  decision  to  treat  Knowledge  as  a 
resource  and  point  out  some  of  the  problems  which  an  organization 
should  expect  to  face.  This  appendix  also  lists  several  research 
areas  wnere  tools  and  theory  need  to  oe  developed  in  order  to 
treat  Knowledge  effectively  as  a corporate  resource.  Perhaps  the 
xey  item  in  the  list  is  tne  development  of  a Knowledge  Resource 
Center  for  the  organization,  a focal  point  where  all  aspects  of 
Knowledge  production  can  oe  monitored  and  directed.  Essential  to 
the  functioning  of  sucn  a center  is  the  collection  of  Knowledge 
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about  data  oases  under  tne  control  ot  the  enterprise,  the  mainte- 
nance of  a dictionary  and  directory  of  data  items  in  any  of  the 
data  oases,  a knowledge  oase  management  system  for  maintaining 
the  center's  own  data  oases,  and  a methodology  for  representing 
to  management  the  Knowledge  and  data  which  the  center  contains. 
The  purpose  ot  the  Knowledge  Resource  Center  is  to  provide 
immediate  answers  to  questions  dealing  with  the  availability  and 
general  location  ot  pertinent  Knowledge,  not  to  answer  specific 
low-level  factual  questions.  It  is  intended  to  give  top-level 
management  a handle  on  the  whole  process  ot  Knowledge-production 
witnin  the  department. 

Other  areas  nave  need  tor  research  in  Knowledge  augmentation. 
Models  of  the  organization  corresponding  to  the  Functional, 
Structural,  or  Physical  views  as  well  as  the  conceptual,  inter- 
nal, and  external  schemas  are  useful  if  a department  is  to  have  a 
proper  understanding  ot  the  role  and  importance  ot  each. 
Knowledge-based  approaches  are  suggested  to  enhance  the  develop- 
ment of  workable,  human-oriented  interfaces  to  the  many  aspects 
ot  a Knowledge  resource  within  the  organization,  e.g.,  natural 
language,  forms,  or  report  production.  Related  to  this  concept 
is  the  need  for  knowledge-directed  naviqational  facilities  to 
assist  Knowledge  resource  users  as  they  wind  their  way  from  data 
base  to  data  base  searching  tor  Knowledge  pertinent  to  their 
tasks.  In  the  area  of  converting  data  into  knowledge  lies  the 
need  for  a methodology  for  applying  validity  values  to  individual 
data  items,  to  relationships  among  data  items,  and  to  entire  data 
bases  according  to  their  source.  This  validity  must  be  computa- 
tionally usaole  in  order  to  arrive  at  validities  for  compound 
situations.  In  addition,  there  is  the  need  for  assistance  in 
correlating  data  from  a variety  ot  sources.  Next  there  is  the 
need  for  semantic  consistency  checks  ot  data  to  be  entered  into  a 
data  base,  i.e.,  filters  on  impossible  and  non-meaningf ul  data. 
Finally,  there  is  the  need  for  Knowledge-based  security  systems 
which  monitor  data  oase  activity,  which  have  an  understanding  ot 
what  the  data  is  about,  and  which  can  make  inferences  about  what 
potential  security  violations  might  arise  by  granting  access  for 
a given  user  to  a particular  piece  of  data  at  a specific  point  in 
time. 


Fach  ot  these  topics,  along  with  many  others,  is  discussed  in 
greater  detail  in  Appendix-1.  For  convenience,  the  topics  nave 
been  ordered  with  reqard  to  the  Structural  View  with  the  research 
areas  being  grouped  under  the  functions  which  were  identified  in 
Sect  ion  b . 
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8.  LOGICAL  SYSTEM  DESIGN 

In  this  section  we  present  a logical  system  design  whicn 
mignt  serve  as  a basis  for  implementing  a knowledge  resource  in  a 
department.  The  details  of  the  implementation  are,  of  course, 
not  yet  firm,  but  tne  overall  model  is  one  which  we  think  pro- 
vides both  the  tools  and  flexibility  which  will  be  needed  if 
knowledge  is  to  become  a departmental  resource.  Additional 
thought  and  design  will  be  required  before  a full-scale  implemen- 
tation is  tried,  and  eacn  department  may  want  to  take  the  general 
design  and  create  their  own  specific  implementation.  Regardless 
of  the  specifics,  we  believe  tnat  the  general  components  which 
are  identified  in  the  design  will  need  to  be  included  in  most 
implementations.  The  architecture  of  a logical  system  design 
wnicn  is  to  be  used  to  develop  a knowledge  resource  must  be  able 
to  survive  tne  inevitable  changes  in  direction  and  technology 
which  are  to  be  expected  with  an  activity  of  this  nature.  Moving 
an  organization  from  tne  world  of  data  processing  to  a world 
where  knowledge  is  a departmental  resource  must  necessarily  be  a 
learning  process  for  all  involved.  Undoubtedly,  the 
organization's  perception  of  knowledge  and  of  what  constitutes  a 
knowledge  resource  will  grow  and  cnange  with  experience. 
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several  aspects  of  tne  design  are  crucial  to  its  success, 
me  following  list  of  general  characteristics  is  indicative  of 
tne  dynamic  environment  which  any  proposed  logical  system  design 
must  be  able  to  support. 


♦ Evolutionary  - the  system  design  must  be  evolutionary 

to  allow  for  an  orderly  transition  from 
tne  current  structural,  functional,  and 
physical  environment  of  the  department. 

♦ Extendable  - the  system  must  be  extendable  from  the 

initial  design  so  that  new  knowledge 
resource  tools  can  be  added  or 
deleted  with  minimal  impact. 

♦ Modular  - the  system  must  be  implemented  in  a mod- 

ular fashion  to  allow  easy  construction, 
easy  maintenance,  and  a failsoft  capa- 
bility. 


♦ Incrementally  Usable  - the  system  must  be  incrementally 

usable  so  that  benefits  can  begin  to  be 
received  prior  to  the  completion  of  the 
entire  system. 

♦ Powerful  - the  system  must  be  powerful  enough  to 

support  all  of  the  ramifications  of 
naving  a knowledge  resource  as  indicated 
in  Sections  2, 3, and  4. 

♦ Cost/Risk  - the  system  design  must  make  maximum  use 

of  existing  technology  both  to  keep  the 
cost  within  reason  and  to  minimize  the 
risk  involved  with  embarking  on  new  re- 
search efforts. 


♦ Enterprise  View  - tne  architecture  of  the  logical  sys- 

tem design  must  support  the  enterprise 
point  of  view  above  individual  parochial 
interests . 

* Learning  Process  - tne  system  must  be  able  to  incorpor- 

ate tne  learning  process  which  the 
organization  will  have  to  go  through  in 
order  to  provide  a knowledge  resource. 

Above  all  else,  the  system  must  De  manageable.  It  must  allow  for 
numerous  points  of  managerial  interaction  and  control  by  the 
humans  it  is  to  serve.  The  system  is  intended  to  provide  a set 
of  tools  to  assist  departmental  personnel  in  accessing  their 
Knowledge,  not  to  replace  them. 
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In  addition  to  the  aoove-mentioned  general  characteristics, 
there  are  several  aspects  of  a knowledge  resource  which  the 
desigh  specifically  addresses.  These  issues  stem  from  the 
preceding  discussions  on  knowledge  independence,  the  need  for 
multiple  interfaces  and  data  managers,  and  a knowledge-pased 
approach.  It  is  our  opinion  that  these  aspects  are  crucial  to 
any  system  design  for  a knowledge  resource.  The  logical  system 
design  of  this  section  is  one  attempt  at  embodying  these  issues. 

(1)  Requirements  tor  any  proposed  system  must  be  gathered  with  a 
clear  understanding  of  the  knowledge  components. 

(2)  Knowledge  independence  must  play  a key  role  in  the  design. 

C 3 ) One  aspect  of  knowledge  Independence  is  the  separation  of 
user  oriented  views  of  knowledge  from  the  computer  oriented 
views . 

(4)  Multiple  user  interfaces  are  required  to  provide  the 
appropriate  view  of  knowledge  which  is  most  natural  to  a particu- 
lar user  category. 

(b)  Multiple  knowledge  resource  tools  are  needed  to  provide  ade- 
quate capabilities  to  meet  differing  knowledge  requirements. 

(6)  A canonical  representation  of  knowledge  will  be  required  tor 
knowledge  snaring  among  distributed  systems. 

(73  Some  facility  will  be  required  to  assist  in  the  navigation 
of  distributed  tactual  and  procedural  knowledge  bases. 

we  nope  that  the  logical  system  design  outlined  below  will  make 
these  Issues  more  explicit  for  the  reader. 

in  Section  b . 2 (the  Structural  View)  we  described  three 
models  of  information  as  postulated  by  the  ANSI/SPARC  group:  the 
internal,  the  external,  and  the  conceptual  models.  in  an  earlier 
paper  [12],  we  identified  a logical  system  desiqn  which 
corresponded  very  closely  to  the  Ansi  model.  For  each  component 
in  the  ANSI  model  there  was  a component  in  the  logical  system 
design:  a Data  Management  Subsystem  ( DMS  3 , a User  interface  Sub- 
system (UiS),  and  a Translation  and  Control  Subsystem  (TCS). 
Figure  8-1  snows  these  three  subsystems. 
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it  an  organization  desires  to  tocus  on  the  tactual  Knowledge 
component  ot  a Knowledge  resource  then  this  early  design  might  be 
satisfactory.  However,  it  does  not  provide  separation  between 
all  of  the  types  of  Knowledge  since  procedural  and  judgmental 
Knowledge  are  not  identified  as  distinct  subsystems.  Therefore, 
we  have  extended  ana  modified  the  logical  system  design  to  pro- 
vide for  separation  of  procedural  and  judgmental  Knowledge.  The 
extended  model  contains  three  subsystems  which  correspond  to  each 
type  of  Knowledge  in  the  taxonomy:  Factual  Knowledge  Subsystem 
CFKS),  Procedural  Knowledge  Subsystem  (PKS),  and  Judgment  Support 
Subsystem  (JSS).  In  addition,  we  have  retained  the  Translation 
and  Control  Subsystem  (TCS)  to  fill  the  continuing  need  for 
integration  between  the  subsystems  of  the  logical  system  design. 
This  extended  design  is  shown  in  Figure  8-2.  The  breaKout  of  the 
components  ot  the  various  subsystems  is  shown  with  their  respec- 
tive subsystem  in  subsequent  figures.  Provision  for  a networK 
environment  such  as  the  one  presented  in  the  Physical  View  of 
Section  b.3  Is  contained  in  the  Translation  and  Control  Subsystem 
and  appears  In  Figure  8-5.  The  actual  software  pacKages  selected 
by  a department  to  comprise  its  Physical  View  are  not  important 
to  the  understanding  ot  the  logical  system  design. 
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8.1  FACTUAL  KNOWLEDGE  SUBSYSTEM 

The  Factual  Knowledge  Subsystem  (FKS)  is  the  purview  of  the 
Data  Base  Administrator.  The  FKS  provides  an  internal  view  of 
the  actual  organization  of  data  and  makes  available  a variety  of 
data  management  software  (access  engines)  as  described  in  the 
Functional  View  of  Section  6.  we  suggest  that  as  a minimum  an 
operating  system-supplied  tile  system,  a file  management  system, 
and  several  data  base  management  systems  (DBMS)  be  included.  The 
operating  system-supplied  tile  structure  will  allow  the  users  to 
create  and  keep  their  own  personal  tiles  which  may  serve  as  a 
personalized  part  of  the  knowledge  resource.  A text  editor  user 
interface  operating  on  standard  tiles  will  provide  the  capability 
to  handle  tne  large  volume  of  written  reports  and  correspondence 
whicn  are  typical  of  today's  modern  organizations.  This  facility 
will  also  allow  this  type  of  valuable  knowledge  to  be  incor- 
porated into  the  deoartment's  knowledge  resource.  The  file 
management  system  provides  standardization  of  the  management  of 
files  where  data  volumes  are  high,  where  limited  logical  views  of 
data  are  needed,  and  where  cost  is  the  overwhelming  considera- 
tion. Several  types  of  DBMS  are  available  for  the  DBA  to  choose 
from  including  inverted  files,  nash-coded,  plex  structure,  and 
relational  systems.  A plex  structure  DBMS  will  allow  the  organi- 
zation to  build  complex  network  views  for  data  whose  structure  is 
relatively  stable.  A relational  DBMS  can  be  used  to  provide 
rapid  access  to  data  whose  structure  is  fairly  dynamic.  Depend- 
ing on  the  manner  of  implementation,  an  inverted  file  system  may 
be  considered  to  be  an  advanced  file  management  system  or  as  a 
special  case  of  a relational  system  where  rapid  retrieval  is 
required  from  a data  base  with  a relatively  stable  structure  and 
a limited  volume  of  updates.  Hash-coded  systems  offer  rapid 
access  to  data  by  specific,  unique  keys.  Each  type  of  DBMS  has 
its  advantages  and  disadvantages.  None  is  suitable  for  all 
users.  Consequently,  a selection  of  factual  knowledge  managers 
should  be  available  if  a DBA  is  to  choose  the  data  manager  most 
appropriate  tor  a given  task.  Figure  8-3  shows  the  Factual 
Knowledge  Subsystem  and  its  generic  components. 
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8.2  PROCEDURAL  KNOWLEDGE  SUBSYSTEM 

rne  Procedural  Knowledge  Subsystem  ( PKS ) Is  tasked  with 
managing  tne  procedural  Knowledge  which  will  be  available  in  the 
Knowledge  resource.  The  PKS  is  divided  into  algorithmic  and 
heuristic  components.  The  former  contains  the  conventional  com- 
puter programs  which  will  perform  most  of  the  routine  processing 
in  the  knowledge  resource  and  includes  such  things  as  statisti- 
cal routines,  mathematical  routines,  and  programmed  algorithms  of 
all  types.  it  also  includes  all  of  the  facilities  which  can  be 
used  to  support  tne  development  of  algorithms  which  will  need  to 
be  added  to  the  knowledge  resource. 

The  heuristic  component  of  the  PKS  will  contain  systems  such 
as  the  knowledge -based  systems  which  were  discussed  in  Section 
S . 1 . Ultimately,  it  is  expected  that  there  will  need  to  be  a 
rich  variety  of  knowledge-based  systems  available  for  use  in  the 
knowledge  resource.  The  PKS  depicted  in  Figure  8-4  will  be 
managed  by  people  called  Procedure  Administrators  who  will  be 
responsible  tor  tne  difficult  task  of  keeping  track  of  the  large 
numbers  of  algoritnmic  programs.  In  addition,  they  will  provide 
technical  assistance  in  the  use  of  the  individual  knowledge-based 
systems  which  are  provided  in  this  subsystem. 
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B.3  JUDGMENT  SUPPORT  SUBSYSTEM 

The  Judgment  Support  Subsystem  (JSS)  is  the  mechanism  through 
which  most  of  the  human  users  will  access  the  knowledge  resource, 
it  also  is  the  component  where  these  humans  will  be  provided  the 
opportunity  to  exercise  their  judgmental  knowledge.  Because  the 
JSS  is  intended  to  serve  as  the  basic  mode  ot  access  to  the 
knowledge  resource,  it  has  been  designed  to  contain  a wide 
variety  of  interfaces  which  are  independent  of  the  other  subsys- 
tems and  which  are  aiso  independent  ot  each  other.  Providing 
such  a variety  of  capabilities  serves  the  dual  purposes  of  main- 
taining maximum  knowledge  Independence  and  supporting  user- 
oriented  views  ot  the  knowledge  resource.  The  JSS  is  shown  in 
Figure  H - 5 . 

The  users  in  an  organization  will  be  faced  with  a complex 
environment  as  more  and  more  of  the  components  of  a knowledge 
resource  are  implemented  and  connected.  We  believe  that  the  sys- 
tem itself  can  be  constructed  in  a fashion  to  supply  the  users 
with  help  in  navigating  and  manipulating  this  environment.  we 
see  this  role  being  filled  by  something  which  we  refer  to  as  a 
"knowledge-based  personal  assistant"  (KBPA)  which  employs  the 
knowledge-based  systems  technology  as  described  in  Section  5. 
rne  KBPA  will  be  tuned  to  a particular  user  and  will  contain  sub- 
stantial amounts  of  knowledge  about  what  that  user  needs  to  do 
his  or  her  job.  It  will  need  to  know  which  types  of  tactual 
knowledge  tne  user  employs  in  his  or  her  work.  It  will  need  to 
know  about  the  different  procedures  which  a given  user  needs  to 
access,  and  it  will  contain  rules  on  the  mission  skills  and  tar- 
gets which  form  the  user's  domain.  In  snort,  it  is  hoped  that 
kbpa's  will  be  able  to  function  as  reasonably  intelligent  assis- 
tants to  helo  the  human  user  function  in  the  knowledge  resource 
environment.  This  proposed  KBPA  is  not  as  far-fetched  as  it 
might  seem.  Knowledge-based  systems  such  as  RITA  [25]  have 
already  been  constructed  to  perform  some  of  the  functions  which 
we  have  just  described.  Increases  in  capabilities  are  needed,  of 
course;  however,  trends  in  the  intelligent  terminal  area  indicate 
that  a "knowledge-based  personal  assistant"  may  be  technically 
possible  within  the  next  few  years. 

The  users  ot  a knowledge  resource  will  need  access  to  a 
variety  of  user  interfaces  which  should  be  standardized 
throughout  the  department.  These  interfaces  should  be  selected 
to  provide  the  broad  range  of  capabilities  which  will  be  needed 
to  support  a user  population  whose  requirements  cover  a full 
spectrum.  we  feel  that  no  single  user  interface  will  be  capable 
ot  satisfying  all  users'  needs.  Instead,  the  key  to  successful 
user  interface  modules  is  to  provide  many  standardized  interfaces 
from  wnicn  a user  or  group  of  users  can  select  those  most  suit- 
able to  their  immediate  needs.  These  interfaces  may  require  dif- 
ferent levels  of  skill  to  operate,  but  each,  in  turn,  could  pro- 
vide significant  differences  in  terms  of  flexibility  and  capabil- 
ity. rne  issue  ot  importance  is  not  whether  one  interface  is 
superior  to  another,  out  rather  whether  users  can  be  provided 
with  a set  of  consistent  and  stable  interfaces  which  are 
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supported  across  all  systems  In  their  department.  The  Judgment 
Support  Suosystem  in  Figure  8-5  identifies  11  different  user 
interfaces.  Undoubtedly,  not  all  user  interfaces  will  oe 
required  by  all  systems,  and  some  useful  interfaces  may  have  oeen 
omitted  from  this  list. 

The  user  interfaces  can  be  grouped  into  two  categories 
depending  on  the  relative  degree  of  independence  that  the  inter- 
face nas  from  the  underlying  data  structures  and  data  managers 
that  it  accesses.  Those  interfaces  having  a relatively  hign 
degree  of  independence  include:  (1)  a subset  of  natural  language 
(English)  which  can  be  used  in  a limited-context  environment  to 
allow  queries  to  be  expressed  in  a more-or-less  natural  language 
form,  (2)  a graphical  interface  which  provides  inf ormation-r ich 
pictorial  representations  of  relatively  large  amounts  of  data 
(such  as  charts,  graphs,  diagrams,  etc.),  (3)  a forms-oriented 
interface  to  allow  both  data  entry  and  retrieval  via  forms  in  an 
attempt  to  simulate  and  replace  the  existing  world  of  paper  forms 
prevalent  in  most  organizations,  (4)  a menu-processor  which 
allows  the  selection  of  functions  from  a list  presented  dynami- 
cally to  the  user,  (5)  a set  of  dialogues  which  permit  interac- 
tion witn  specific  levels  of  users  in  a vocabulary  and  format 
whicn  is  commensurate  with  the  user's  position  and  function,  and 
(6)  a transaction-oriented  interface  which  allows  rapid  response 
to  terse  commands  which  represent  individual,  independent  actions 
to  be  taken. 

Those  interfaces  which  require  a relatively  high  degree  of 
dependence  on  the  specific  underlying  data  manager  (i.e.,  low 
independence)  include  (7)  a query  language  (ot  which  there  may  be 
several);  it  is  hoped  that  tne  need  for  a separate  query  language 
will  eventually  be  ooviated  by  the  natural  language  subset  inter- 
face, (8)  a relational  interface  which  allows  greater  flexibility 
in  query  expression,  but  which  currently  requires  a relational 
view  of  data,  (9j  one  or  more  programmatic  interfaces  to  specific 
programming  languages  tor  use  by  application  programs  which  are 
intended  to  perform  calculations  based  on  the  data  being 
accessed,  (10)  a navigational  interface  which  permits  tne  user  to 
browse  or  navigate  on  two  levels:  (a)  when  tightly  connected  to 
a structured  data  base  management  system,  and  (b)  when  accessing 
the  knowledge  resource  description  contained  in  the  Translation 
and  Control  Subsystem,  and  (11)  a text  editor  interface  which 
provides  the  capability  of  interactively  enterinq  and  editing 
data  and  textual  material  which  is  stored  in  standard  files. 

r wo  final  points  about  the  user  interfaces  remain  to  be  con- 
sidered. First,  a set  ot  common  user  utilities  such  as  sorting, 
report  generation,  etc.  is  required  and  needs  to  be  accessible 
from  each  user  Interface.  by  placing  these  utilities  close  to 
the  user  interface,  problems  such  as  oitferent  collating 
sequences  are  made  easier.  Second,  another  layer  ot  software,  in 
addition  to  the  KHP A , may  Decome  necessary  between  the  users  and 
the  various  user  interfaces.  Its  function  is  to  provide  stand- 
ardized user  interfaces  and  protocols  which  have  command 
languages  for  selecting  the  various  user  interfaces,  moving  from 
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one  to  another,  and  calling  on  the  utilities.  A "universal" 
interface  perhaps  is  enterprise-dependent  but  may  also  be  user- 
dependent  in  the  sense  that  whole  classes  ot  users  may  require  a 
common  interface  unique  from  other  classes. 

8.4  TRANSLATION  and  CONTROL  SUBSYSTEM 

The  Translation  and  Control  Subsystem  (TCS)  is  the  mechanism 
which  integrates  all  of  the  other  subsystems  of  the  logical  sys- 
tems desiqn.  Figure  8-b  shows  some  of  the  modules  which  will  be 
required  by  the  Translation  and  Control  Subsystem.  Central  to 
the  translation  process  is  a canonical  form  for  data  structures 
and  data  formats  which  is  sufficiently  general  to  accommodate  the 
representation  of  any  data  structure  employed  by  a data  manager, 
any  form  of  representation  employed  by  a user,  and  any  data  for- 
mat employed  by  a computer  with  which  it  must  communicate.  It 
must  allow,  too,  for  direct  linkages  between  data  structure 
dependent  user  interfaces  and  the  appropriate  data  managers 
without  throwing  up  a roadblock  of  unnecessary  translation.  It 
is  important  to  keep  clear  the  difference  between  the  canonical 
representation  and  the  mapping  mechanism  necessary  between  this 
canonical  form  and  the  other  modules  of  the  system.  This  mapping 
process  is  termed  translation,  while  the  canonical  form  is  the 
intermediate  representation  through  which  the  translation  is  per- 
formed. 

The  TCS  does  more,  however,  than  just  translate  between  the 
judgmental  support  subsystem  and  the  procedural  and  tactual 
knowledge  subsystems  (no  trivial  task  in  itself).  The  TCS  incor- 
porates the  ability  to  access  all  types  of  knowledge  throughout 
the  entire  knowledge  resource.  Thus,  the  Translation  and  Control 
Subsystem  must  contain  a data  dictionary  and  data  directory  con- 
sistent with  the  entire  department  as  well  as  data  location  algo- 
rithms to  send  requests  to  the  appropriate  data  managers  wherever 
they  may  be  located  (locally  or  in  a computer  network  --  see  Fig- 
ure 8-7).  The  TCS  must  provide  the  capability  to  the  users  to 
access  one  or  more  local  data  bases,  one  or  more  remote  data 
bases,  or  some  combination  ot  these.  Presumably,  in  the  early 
stages  of  development  explicit  directions  from  the  user  will  be 
required  to  determine  the  particular  data  bases  to  be  accessed. 
In  more  advanced  stages,  the  system  may  be  expected  to  determine 
the  range  of  distribution  required  from  the  context  of  the  user. 
In  tnis  capacity  the  dictionary/directory  plays  a key  role  and 
must  ne  kept  reasonably  accurate.  It  does  not,  however,  have  to 
contain  all  data  about  data;  a mere  outline  or  synopsis  may  suf- 
fice to  direct  the  search  to  potentially  relevant  tiles  and  data 
oases. 

The  Translation  and  Control  Subsystem  also  is  the  natural 
place  to  establish  a connection  to  the  department's  knowledge 
resource  via  a computer  network  (see,  again,  Figure  8-7).  The 
canonical  representation  provides  a common  facility  for  sharing 
knowledge  among  disparate  systems  while  also  feeding  data  about 
the  knowledge  bases  themselves  into  some  centralized  enterprise- 
level  control  mechanism  so  that  an  overall  organizational  view 
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can  oe  maintained.  in  this  capacity  a TCS  knowledge-based  system 
( TCS/KbS)  will  be  required  to  allow  such  activities  as  Inductive 
and  deductive  inferenclng  with  rule  sets  relevant  both  to  the 
local  system  environment  and  the  enterprise  knowledge  resource  as 
well.  Because  the  Translation  and  Control  Subsystem  is  expected 
to  employ  canonical  forms  for  data  and  procedural  knowledge,  the 
amount  of  effort  needed  to  feed  data  and  knowledge  into  the 
enterprise  knowledge  resource  should  result  in  minimal  overhead. 
That  is,  the  features  tor  a knowledge  resource  center  are  built- 
in,  not  addeo-on. 

One  final  function  of  the  Translation  and  Control  Subsystem 
is  to  exercise  control  over  the  transition  between  data  managers 
and  user  interfaces.  In  this  capacity,  the  TCS  must  have  some 
data  management  capabilities  of  its  own,  must  maintain  some  data 
bases  relevant  to  its  special  function,  and  must  coordinate 
matters  of  security,  integrity,  recovery,  authorization,  and  con- 
current access.  These  problems  are  especially  difficult  in  a 
distributed  environment  where  different  data  managers  ana  even 
different  computers  may  be  involved.  Considerable  research  in 
these  areas  will  be  needed  before  a final  working  system  can  be 
aeve 1 oped . 
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It  should  be  pointed  out  that  it  is  not  necessary  that  every 
physical  implementation  ot  this  logical  system  contain  every 
module  (factual  or  procedural  knowledge  component  or  every  com- 
ponent in  the  judgment  support  subsystem).  what  we  are  advocat- 
ing is  that  the  various  modules  be  available  tor  system  implemen- 
tors to  choose  from  according  to  their  specific  requirements.  We 
emphasize  the  need  to  standardize  on  the  various  user  interfaces 
so  that  users  may  transfer  among  systems  throughout  a department 
and  effectively  see  no  difference  in  the  command  languages  or 
data  presentation  no  matter  which  hardware  they  use. 

The  logical  system  design  which  we  have  described  addresses 
to  some  extent  the  specific  knowledge  issues  outlined  at  the 
beginning  of  this  section.  The  separation  of  factual  knowledge 
from  procedural  knowledge  is  addressed  by  the  separation  of  the 
factual  knowledge  subsystem  from  the  procedural  knowledge  subsys- 
tem as  well  as  by  the  distributed  dictionary  and  directory  and 
distributed  tactual  and  procedural  knowledge  locators  of  the 
translation  and  Control  Subsystem*  Multiple  user  interfaces  are 
accounted  for  as  are  multiple  data  managers  for  more  natural 
views  of  knowledge.  Canonical  representations  of  factual  and 
procedural  knowledge  are  addressed  in  the  TCS.  Finally,  a facil- 
ity for  navigating  the  knowledge  resource  is  included  in  the 
navigational  user  interface  which  can  be  used  to  access  the 
directory  and  the  factual  and  procedural  knowledge  locator 
modules. 

Two  additional  issues  remain  to  be  discussed:  data  acquisi- 
tion and  archival  storage.  Data  acquisition  is  really  just  a 
process  which  may  employ  one  or  more  ot  the  user  interfaces 
listed  above  (e.g.,  pr oqrammat ic , transaction,  or  forms). 
Departmental  standardization  on  the  data  entry  function  can  go  a 
long  way  toward  easing  the  problem  of  transferring  personnel 
among  various  data  entry  appl icat ions . 

The  question  ot  archival  storage  interface  is  left  open. 
Several  alternatives  are  possible,  depending  on  requirements  and 
resources.  A mass  storage  device  may  be  appended  as  a back-end 
to  the  tile  system  in  the  logical  design  (for  example,  as  in  the 
IBM  38SO);  or  it  may  be  included  as  an  additional  data  manager 
(employing  translation  via  the  TCS);  or  it  may  be  implemented  as 
a stand-alone  centralized  system  accessible  through  the  transla- 
tion and  control  subsystem  via  the  network  (as  with  the  Datacom- 
puter).  In  any  event,  care  must  be  taken  to  insure  that 
knowledge  placed  in  arcnlval  storage  will  always  be  retrievable. 
By  this  we  mean  that  tactual  knowledge  stored  in  a form  appropri- 
ate tor  a particular  data  manager  may  be  unusable  in  future  years 
should  that  data  manager  be  abandoned  or  replaced  by  the  depart- 
ment. Some  means  must  be  provided  for  storing  all  data  via  a 
single  mechanism,  and  that  mechanism  must  be  retained  tor  the 
life  ot  the  archival  storage.  The  canonical  representation  which 
are  to  oe  found  in  tne  TCS  may  be  the  appropriate  vehicle  tor 
such  long-term  storage  and  access. 
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No  claims  are  made  at  this  time  about  the  size  ot  machine 
needed  to  implement  tnis  system.  l'he  fact  that  only  parts  of  the 
entire  design  may  be  desired  in  a given  installation  indicates 
that  some  so-called  minicomputers  may  be  appropriate.  Further- 
more, the  logical  system  structure  described  above  need  not  be 
implemented  on  a single  machine.  In  fact,  the  various  subsystems 
may  each  be  implemented  on  a different  computer  tor  modularity, 
expandabi 1 i ty , performance,  cost,  or  a combination  of  reasons. 
Use  of  the  various  interfaces  and  data  managers  need  not  wait  for 
the  development  of  the  translation  and  control  subsystem,  nor 
must  one  package  be  dependent  on  the  development  ot  all  the  oth- 
ers. Direct  linkages  ot  user  interfaces  to  oata  managers  can  be 
implemented  as  the  modules  are  developed,  but  with  the  proviso 
that  such  direct  linkages  can  be  broken  easily  when  the  Transla- 
tion and  Control  Subsystem  becomes  available,  bach  module  can  be 
developed  individually  (although  with  a coordinated  goal  in 
mind),  and  tne  system  can  be  implemented  in  phases  according  to 
available  resources  and  technological  advances.  Once  the  various 
subsystems  have  been  stabilized,  many  of  the  functions  may  be 
moved  to  firmware  for  greater  processing  efficiency.  Parallel 
processing  may  also  be  employed  in  any  subsystem  to  further 
improve  the  response  to  the  user. 

8.S  UNIX  PROTOTYPE 

Some  preliminary  work  nas  begun  toward  testing  the  feasibil- 
ity ot  tne  logical  system  design  described  above  using  the  UNIX 
operating  system  [ 3 b J on  Digital  Equipment  Corporation  PDP-11 
computers.  A discussion  of  the  particular  ideas  and  software 
products  involved  is  contained  in  Appendix-2, 
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0.  COUCLiJS  1 UNS  AND  RECOMMENDATIONS 

A major  premise  o t tnis  paper  is  that  most  Federal  depart- 
ments are  "Knowledge  agencies."  By  this  we  mean  that  their  pri- 
mary product  is  Knowledge,  oe  it  tactual  Knowledge  about  data 
related  to  the  departmental  mission,  procedural  Knowledge  about 
the  techniques  employed  to  process  that  lntormation,  or  the  judg- 
mental Knowledge  by  which  policy  and  decisions  are  made.  This 
total  Knowledge  is  central  to  the  existence  ot  a Federal  depart- 
ment and  should  be  formally  recognized  as  the  basic  resource  that 
it  is.  As  we  said  in  Section  i,  the  orientation  of  the  authors 
nas  been  primarily  toward  governmental  activity,  and  the  recom- 
mendations wnich  follow  reflect  that  orientation.  The  applica- 
tion ot  these  remarKs  to  other  types  of  organizations  is, 
perhaps,  the  subject  of  another  paper. 

9.1  KNOWLEDGE  IS  A BASIC  RESOURCE 

The  formal  recognition  of  Knowledge  as  a basic  departmental 
resource  will  have  widespread  ramifications  as  indicated  in  this 
paper.  The  most  visible,  perhaps,  might  be  the  recognition  of 
the  new  functions  which  will  be  needed  to  maintain  the 
organization's  Knowledge  resource  and  to  insure  compatibility 
among  all  of  the  various  groups  and  projects.  Consistent  with 
this  philosophy  is  the  need  for  line  and  project  managers  to 
reorganize  their  approach  to  Knowledge  applications  and  systems 
design.  Knowledge  independence  Cthe  formal  separation  and 
specification  of  Knowledge  types  and  contexts)  will  oe  essential, 
we  repeat  that  the  control  of  Knowledge  applications  should  not 
be  removed  from  the  purview  of  the  various  elements  of  expertise, 
but  that  enterprise-wide  controls  and  guidelines  must  be  main- 
tained over  the  representation  and  sharing  of  the  Knowledge 
employed  by  the  various  applications.  Obviously,  for  any  program 
ot  this  magnitude  and  wide-reaching  impact,  the  support  of  the  top 
officer  ot  the  department  is  very  important.  Such  commitment  by 
top  management  will  help  to  provide  the  direction  and  support 
needed  to  accomplish  the  goal  ot  a Knowledge  resource. 

9.2  KNOWLEDGE -BAS ED  SYSTEMS  EXPERIMENTATION  IS  NEEDED 

Considerable  research  will  be  required  in  both  the  managerial 
and  technical  components  ot  a Knowledge  resource.  In  Appendix-1 
we  list  numerous  areas  tor  research  and  development  without 
attempting  to  assign  priorities  to  those  endeavors.  An  area  war- 
ranting extensive  investigation  in  the  near  future  is  that  ot 
Knowledge-based  systems  (see  Section  5 ) . Some  preliminary  study 
and  evaluation  efforts  are  already  underway  in  this  field  but  a 
more  extensive  program  of  testing  this  technology  against  depart- 
mental Knowledge  applications  is  needed  to  gain  valuable  exper- 
tise in  tneir  use  and  a deeper  understanding  of  the  problems 
involved.  The  recent  or  imminent  departure  of  some  ot  the 
most  knowledgeable  and  skilled  civil  servants  emphasizes  the 
need  to  organize  formally  and  retain  at  least  a part  ot  their 
invaluable  exoertise.  Knowledge-based  systems  might  serve  that 
function,  out  the  experts  must  be  made  available  to  supply  the 
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appropriate  Knowledge  to  tne  system  in  a process  which  can  taKe 
several  years  to  accomplish. 

9 . i KNUWLEDGE  I NDEPENDENCE  IS  CRUCIAL 

The  issue  of  Knowledge  independence  is  also  a critical  aspect 
which  should  be  considered  oy  system  analysts  in  designing  future 
systems  tor  departmental  projects.  In  Section  8 we  presented  a 
logical  system  design  which  was  intended  to  identify  some  of  the 
basic  components  of  a Knowledge  resource.  The  authors  do  not 
advocate  that  this  design  is  the  only  design  possible,  nor  even 
that  it  is  the  best;  rather,  we  nave  included  the  design  as  a 
demonstration  of  tne  Kind  of  system  which  a Knowledge  resource 
mignt  be  based  upon.  The  design  provides  for  tne  separation  of 
the  factual  Knowledge  from  procedural  Knowledge  and  judgmental 
Knowledge  along  wltn  the  provision  of  some  sort  of  translation 
and  control  mechanism  to  allow  tne  different  components  to  worK 
toaether.  This  embodiment  of  Knowledge  independence  offers  the 
advantages  of  permitting  data  sharing  (really  Knowledge  sharing) 
amonj  departmental  applications,  supplying  a limited  number  of 
(standardized)  user  interfaces  to  the  Knowledge  resource,  and  a 
mechanism  for  monitoring  and  understanding  the  flow  of  Knowledge 
among  tne  various  elements  of  the  organization  from  a centralized 
point.  Another  important  aspect  of  Knowledge  independence  is  the 
need  to  recognize  and  separate  heuristic  procedural  Knowledge 
from  what  is  thought  to  be  algorithmic  procedural  Knowledge.  The 
recognition  of  this  separation  can  lead  to  significant  changes  in 
tne  current  methods  of  designing  systems  ano  writing  software. 

9.4  JOINT  EFFORTS  ARE  ESSENTIAL 

A department  should  not  attempt  to  build  a Knowledge  resource 
completely  alone.  No  mention  has  been  made  of  the  expected  cost 
of  sucn  an  endeavor  (indeed,  a cos t /bene f i ts  trade-off  analysis 
should  oe  performed),  but  there  is  no  need  for  any  organization 
to  incur  all  of  the  researcn  and  development  costs  necessary  tor 
such  a program.  Tne  Defense  Advanced  Research  Projects  Agency 
(DARPA),  the  Office  of  Naval  Research,  and  the  National  Science 
Foundation  (NSF)  are  just  a few  of  the  agencies  which  fund 
researcn  in  the  information  systems  area.  Departments  should 
Decome  very  active  in  stating  their  requirements  for  and  in  par- 
ticipating in  the  research  which  these  organizations  sponsor.  A 
unifieg  departmental  position  on  what  will  be  needed  to  build  and 
operate  their  Knowledge  resource  is  essential  to  obtaining  such 
vital  support.  In  addition  to  seeKinq  other  sources  of  funding, 
a department  should  also  seeK  out  and  collaborate  with  other 
departments  which  might  be  interested  in  developing  tneir  own 
Knowledge  resources.  Indeed,  the  development  of  Knowledge  within 
a given  department  is  of  little  worth  without  the  ability  to  com- 
municate their  Knowledge  to  others.  Departments  can  supply  valu- 
able Knowledge  to  assist  each  otner  in  their  tasKs,  but  a coordi- 
nated methodology  will  be  required.  Experiences  with  the  present 
computer  networxs  can  attest  to  the  utility  and  difficulty  of 
such  Knowledge  sharing  among  agencies.  we  believe  that  the  ideas 
outlined  in  this  paper  can  serve  as  a partial  basis  for  that 
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metnodology . 

O.b  A KNOWLEDGE  RESOURCE  METHODOLOGY  IS  NEEDED 

The  final  recommendation  is  that  Federal  departments  work  to 
develop  a methodology  tor  developing  knowledge  resources.  We 
have  made  some  recommendations  in  this  paper  concerning  general 
specifications  for  system  design.  Much  more  specific  thinking  is 
necessary  before  the  knowledge  resource  philosophy  can  be  effec- 
tively institutionalized  in  the  major  Federal  departments. 
Indeed,  more  tacts  and  better  arguments  will  be  needed  before 
top-level  departmental  management  can  be  expected  to  commit  to 
implementing  such  an  approach.  We  recommend  that  task  forces  be 
appointed  to  study  and  expand  the  definition  of  a knowledge 
resource  philosophy.  The  task  forces  should  identify  the  short- 
range  and  long-range  conseguences  of  embracing  the  philosophy 
wnich  they  have  refined.  Finally,  plans  must  be  drawn  up  which 
will  identify  the  actions  whicn  will  need  to  be  taken  in  oraer  to 
implement  knowledge  resources  for  each  of  the  various  depart- 
ments. Such  a plan  might  contain  (among  others)  recommendations 
to 

* Identify  existing  problems  where  having  a 
knowledge  resource  could  offer  improved  solutions. 

* Establish  ana  nurture  appropriate  links  between 
Federal  departments  in  order  to  begin  knowledge 
sharing  between  departments. 

* Expand  efforts  in  the  test  and  evaluation  of 
knowledge-based  system  technology. 

* Establish  Knowledge  Resource  Technology  Transfer 
Laborator ies . 

* Develop  a methodology  for  performing  systems 
analysis  under  a knowledge  resource  philosophy. 

* Develop  and  experiment  with  the  logical  system 
design  concepts  (new  user  interfaces,  new  knowledge 
managers,  canonical  knowledge  representation  and 
translation,  and  knowledge  independence). 

* Identify  and  use  joint  funding  possibilities  for 
knowledge  resource  development  efforts. 
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PROBLEMS  IN  IMPLEMENTING  A KNOWLEDGE  RESOURCE 


A- 1.1  INTRODUCTION 

rne  recognition  of  Knowledge  as  a corporate  resource  of  a 
department  will,  in  most  instances,  oe  a long  drawn-out  process. 
I'nere  will  oe  many  problems  to  be  confronted  along  the  way;  some 
can  oe  foreseen,  some  cannot.  There  will  be  political  problems, 
economic  problems,  technical  problems,  and  managerial  or  struc- 
tural problems.  Some  degree  of  structural  reorganization  may  be 
required.  A new  philosophy  of  organizational  ownership  and 
responsibility  for  knowledge  will  have  to  be  established  with  a 
strong  sense  of  direction  and  support  from  top-level  management. 
Only  top-level  management  has  the  power  to  deal  with  the  politi- 
cal, economic,  and  structural  problems  head-on.  Only  after  these 
problems  nave  been  solved  can  a unified  corporate  approach  to  a 
Knowledge  resource  succeed.  Even  with  their  solution,  however, 
there  will  remain  many  technical  problems  in  acquiring, 
representing,  and  transmitting  Knowledge.  Research  in  these 
vital  areas  is  needed  now. 

In  this  Appendix  we  address  some  of  the  many  issues  which 
must  oe  faced  by  an  organization  in  attempting  to  develop  a cor- 
porate policy  which  establishes  a Knowledge  resource.  The  list 
of  issues,  though  extensive,  is  by  no  means  exhaustive.  It  does, 
however,  point  out  some  of  the  more  crucial  problem  areas  and 
deficiencies  of  current  technology  in  this  field  and  indicates 
some  topics  where  more  research  is  necessary.  The  list  is  organ- 
ized around  a blend  of  the  Structural  and  Functional  Views  of 
Section  6 of  the  paper  with  problem  areas  being  made  explicit 
tnrouqn  the  Physical  View. 

A-1.2  CUNCEP1UAL  MODEL 

There  should  be  someone  such  as  an  Enterprise  Administrator 
CEA)  with  overall  resDonsioility  for  implementing  and  maintaining 
tne  Knowledge  resource.  An  FA  should  be  concerned  with  the 
proper  working  of  each  of  the  functional  data  management  areas 
(file  systems,  tile  management  systems,  data  base  management  sys- 
tems, and  Knowledge  base  management  systems)  and  with  maintaining 
tne  proper  flow  of  data,  information,  and  Knowledge  between  tne 
functional  units.  An  EA  snould  not  be  as  concerned  with  the 
technical  operation  of  each  individual  data  manager  as  with  tne 
overall  performance  of  the  department  with  respect  to  its 
Knowledge  resource.  Tne  purview  of  the  EA  covers  not  only 
current  day-to-day  informational  response,  but  long-term 
Knowledge  production  as  well.  An  EA,  if  the  function  is  created 
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at  ail,  should  be  a high  level  official  who  is  to  be  responsible 
tor  the  Knowledge  resource  and  as  such  he  or  she  should  report 
directly  to  top  management.  In  this  fashion  the  EA  is  given 
equal  standing  with  the  other  managers  who  are  responsible  for 
managing  other  basic  departmental  functions. 

An  Enterprise  Administrator  will  undoubtedly  require  the 
assistance  of  a staff  in  addition  to  needing  a number  of  tools 
including  a powerful  Knowledge  resource  facility  to  Keep  tracK  of 
the  many  data  elements,  tile  structures,  data  oases,  and  flows 
which  comprise  the  Knowledge  of  the  Agency.  It  is  through  the 
office  of  the  EA  that  top  management  maKes  its  requests  for 
high-level  information  aoout  the  functioning  of  the  Knowledge 
resource  of  the  Agency.  It  is  the  EA  who  constantly  watches  for 
Knowledge  and  information  bottlenecKs  and  problem  areas  and  who 
is  responsible  for  fixing  them  before  they  become  critical. 

A-l.2.1  Knowledge  Resource 

Before  embarKing  on  a Knowledge  resource  policy,  a department 
must  have  a worKing  definition  of  the  meaning  and  implications  of 
the  Knowledge-as-a-resource  philosophy  as  it  applies  specifically 
to  their  department.  Estimates  of  the  political,  economic, 
technical,  and  structural  impact  must  be  presented  to  top  manage- 
ment it  they  are  to  avoid  unfavorable  surprises  later  on.  Top 
management,  of  course,  will  not  agree  to  declare  Knowledge  to  be 
a corporate  resource  without  an  appreciation  for  the  significance 
of  such  a declaration.  The  significance  of  where  the  functions 
to  be  performed  are  placed  will  not  be  lost  on  the  other  levels 
of  the  organization,  and  this  placement  will  greatly  affect  how 
the  people  perceive  and  deal  with  this  new  function.  Assigning 
tne  newly  identified  functions  to  elements  steeped  in  one  of  the 
three  contexts  (for  example,  the  computer  department)  will  have 
the  effect  of  declaring,  at  least  structurally,  that  Knowledge 
really  is  not  viewed  as  a basic  resource  of  equal  importance  to 
all  divisions  of  the  department. 

Rarely  does  a department  act  in  a complete  vacuum.  Quite 
often  it  interacts  with  other  enterprises  which  may  direct  its 
activities  or  function  as  a customer  for  its  products.  There 
will  be  varying  amounts  of  Knowledge  exchanged  between  the 
department  and  these  other  organizations.  Someone  needs  to 
define  the  degree  of  interaction  and  the  relationship  of  the 
department  to  other  organizations  including  the  volume,  direc- 
tion, and  importance  of  various  data  and  information  flows. 
Similarly,  someone  should  develop  a model  of  a macro-view  of  the 
department  itself  and  the  relationships  among  the  various  sub- 
divisions within  it.  This  model  should  include  tasKing  require- 
ments, data  and  information  flows,  and  the  existing  managerial 
structure  of  the  organization.  in  addition,  the  organization 
will  need  a model  of  its  Knowledge  resource  and  of  the  processes 
py  which  the  employees  acquire  and  maintain  their  Knowledge. 
These  models  not  only  will  serve  as  a representation  of  goals  and 
current  status,  but  they  can  also  provide  the  organization  with  a 
means  for  testing  the  impact  of  various  hypothetical  changes  in 
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requirements  or  organizational  structure.  Current  modeling  tecn- 
niques  may  be  adequate  for  tnis  process,  put  it  is  doubtful  that 
any  such  models  have  actually  been  constructed.  Experimentation 
in  the  design  and  use  of  these  models  is  needed  to  uncover  unex- 
pected problems  ana  applications. 

A - l .2.2  Policy 

The  department  will  need  to  establish  policies  tor  the  organ- 
ization in  data  management  functional  areas  as  well  as  policies 
for  the  human/machine  and  machine/machine  interfaces  which  might 
affect  a Knowledge  resource.  selection  guidelines  will  need  to 
oe  established  for  data  management  software.  Evaluation  pro- 
cedures, sample  data  bases,  benchmark  tests,  and  checks  on  the 
consistency  of  a proposed  system  with  the  overall  data  management 
plan  of  the  organization  will  all  need  to  be  developed.  The  pol- 
icy should  offer  direction  tor  data  management  research  in  addi- 
tion to  operational  activities.  These  policies  will  need  to  be 
coordinated  with  other  organizations  outside  of  the  department  as 
appropriate  to  insure  compataDi li ty  in  inter-organizational  tran- 
sactions which  must  adhere  to  applicable  standards  policies, 
outside  organ  1 zat ions  also  frequently  set  the  information  systems 
standards  policy  which  the  department  must  adhere  to,  and  the 
organization  must  keep  abreast  of  such  policies  and,  wherever 
possible,  influence  them  before  they  are  issued.  finally,  it  is 
sugqested  that  environmental  impact  studies  be  required  from 
those  projects  which  propose  data  management  systems  contrary  to 
established  guidelines.  These  studies  should  address  such  topics 
as  the  anticipated  need  for  knowledge  sharing  with  other  systems 
and  plans  for  future  migration  to  next-generation  equipment. 
They  snould  also  include  studies  on  the  costs  which  the  rest  of 
the  department  miqht  incur  in  the  future  due  to  the  inclusion  of 
the  non-standard  system.  The  production  of  useful  guidelines  for 
the  preparation  of  meaningful  impact  studies  is  an  area  needing 
furtner  research. 

A- 1 . 2 . 3 Standards 

Standards  is  an  area  which  few  people  like,  but  which  most 
people  feel  is  necessary  in  a resource-sharing  environment.  It 
is  a necessary  task  to  establisn  a policy  regarding  all  levels  of 
standardizat ion  as  it  impacts  the  knowledge  resource  in  the 
enterprise.  Someone  must  determine  effective  methods  for  enforc- 
ing standards  policies,  establish  a policy  for  resolving  con- 
flicts between  multiple  standards  as  imposed  by  external  organi- 
zations, and  develop  tecnniques  fot  automatic  translation  between 
standards  at  all  levels.  In  situations  where  there  are  different 
Kinds  of  hardware  and  software  which  are  intended  to  snare  data 
and  Knowledge,  a great  numoer  of  areas  are  potential  targets  tor 
standardization.  This  may  include  techniques  and  procedures  as 
well  as  hardware  and  software. 

it  is  recognized  that  all  of  the  costs  of  standardization 
must  not  De  transferred  to  the  end  users  of  the  data  oases  by 
requiring  them  all  to  view  the  data  in  exactly  the  same  way. 
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since  some  degree  ol  s t anda r ds- t r ans l at i on  will  be  needed  in  any 
case,  additional  research  is  necessary  to  determine  how  much  of 
the  standards  burden  can  be  shouldered  by  this  type  of  software, 
tnus  freeing  users  from  continuous  and  onerous  training  in  stan- 
dards. The  view  of  data/knowledge  which  one  employs  is  a func- 
tion of  one's  position  within  the  departmental  structure.  It  is 
also  a function  of  the  context  in  which  that  data/knowledge  is 
used.  Multiple  levels  of  standards  (which  encompass  a hierarchy 
of  detail)  are  necessary  to  provide  the  proper  perspective  for 
different  classes  of  users.  It  is  unwise  and  undesirable  to 
force  the  clerk  in  tne  field  to  maintain  a view  of  the  data 
identical  to  that  held  by  the  Secretary.  The  classical  view  of 
standards  holds  that  this  conformity  is  the  main  goal  of  stan- 
dardization. un  the  contrary,  the  goal  of  standardization  should 
be  to  facilitate  communications  among  different  divisions  of  the 
department  by  agreeing  on  standardized  concepts,  not  standardized 
names.  The  terms  in  the  daily  vocabulary  of  the  clerks  are 
user-spec  i f ic , natural,  convenient,  and  necessarily  quite 
detailed.  On  the  other  hand,  the  vocabulary  of  the  Secretary  is 
more  general,  dealing  with  summary  information  at  a high  level. 
Meitner  group  can  function  with  the  other's  vocabulary,  nor 
should  tney  have  to,  as  long  as  the  concepts  of  the  knowledge 
passed  between  them  are  clear.  This  is  the  purpose  of  the  single 
conceptual-schema  / multiple  external-schema  approach  outlined  in 
Section  6.2.  Of  central  importance  is  the  ability  to  define  and 
maintain  the  context  of  reference  to  particular  data  items  (or 
data  bases).  Localized  vocabulary  should  be  adequate  tor  local 
context.  Only  when  access  is  required  of  more  qlobal  data  must 
the  terminology  differences  be  resolved.  Extensive  thinking  and 
experimentation  needs  to  oe  done  in  this  area  before  an  effective 
implementation  can  be  obtained. 

A- ] . 2 . 4 Training 

Considerable  traininq  will  be  required  tor  an  Enterprise 
Administrator  and  staff,  and  they,  in  turn,  will  need  to  educate 
others  in  the  policies  wnich  must  be  followed.  The  organization 
will  require  advanced  knowledge  in  the  following  areas:  concep- 
tual schema  aesign;  organizational  dictionary  and  directory 
development  and  use  (see  Section  A-l.2.6  below);  existing  policy, 
standards,  and  organizational  structure;  departmental  goals, 
applications , and  need  for  knowledge  sharing  (both  within  and 
outside  the  department);  data  base  administration;  the  state-of- 
the-art  in  data  management;  long-range  planning  and  forecasting; 
and  general  management  techniques.  Many  of  these  subject  areas 
are  highly  dynamic  and  the  organization  will  constantly  need 
training  to  keep  up-to-date  in  these  fields.  Someone  in  the 
organization  must  have  responsibility  for  training  the  rest  of 
the  department  in  these  areas:  the  philosophy  of  treating  data 
and  knowledge  as  a corporate  resource;  policies  (see  2 above) 
whicn  have  oeen  established;  and  tne  use  of  the  conceptual  schema 
designed  for  the  department 
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A-1.2.b  Knowledge  Resource  Presentation 

effective  management  ot  the  Knowledge  resource  of  a depart- 
ment may  regulre  a centralized  information  system  which  is 
separate  and  distinct  from  the  other  information  systems  ot  the 
enterprise  and  which  can  be  used  oy  (1)  some  executive  staff  off- 
icers to  monitor  the  inter-system  flow  of  information  within  the 
department  and  by  (2)  top  management  to  answer  high-level 
reguests  for  information  concerning  the  functioning  of  the  organ- 
ization in  general  (e.g.,  "where  do  we  have  information  on  ...?" 
or  "what  information  do  we  have  that  would  help  us  assess  the 
impact  of  closing  the  office  in  A centralized  facility 
called  the  Knowledge  Resource  Center  ( KRC ) , which  is  dedicated  to 
the  support  of  the  department  as  a whole  appears  necessary.  The 
KRC  snouid  oe  a dedicated  computer  system  with  a data  base  con- 
taining summary  information  about  the  other  data  bases  of  the 
department.  This  data  base  can  be  expected  to  be  driven  automat- 
ically by  receiving  its  input  from  the  other  data  bases  in  the 
organization  and,  hence,  it  should  be  accurate  and  up-to-date. 
It  should  provide  special  user  interfaces  which  are  suitable  for 
handling  the  Kinds  of  questions  which  top  managment  asKs,  The 
KRC  concept  appears  to  De  capable  of  supporting  what  Robert 
Antnony  termed  the  "strategic  planning"  function  of  the  enter- 
prise [ J 6 J . Ihis  function  is  also  recognized  as  tne  top  layer  of 
an  integrated  Management  information  System  (MIS).  MIS's,  to 
date,  nave  been  marKed  by  a notable  lacK  of  success  C 3 7 J . 
Perhaps  one  of  the  major  reasons  for  this  state  of  affairs  has 
oeen  tne  failure  of  implementors  to  recognize  the  need  for  a cen- 
tralized facility  such  as  the  Knowledge  Resource  Center  to  sup- 
port tne  Mis  and  to  support  the  specific  Knowledge  needs  ot  top 
and  middle  management. 

It  must  be  recognized  that  there  will  be  many  problems  to  be 
overcome  in  maintaining  the  KRC.  In  particular,  there  will  be 
Droolems  in  connecting  tne  KRC  witn  all  of  the  scnemas  in  tne 
various  data  bases  ot  tne  department.  Such  automatic  connections 
are  necessary,  however,  if  the  costs  tor  the  KRC  are  to  be  held 
witnin  acceptable  bounds.  Once  the  data  resides  in  the  KRC  there 
will  oe  problems  with  developing  techniques  for  automatical ly 
summarizing  information,  and  discovering  effective  means  for 
presenting  this  information  (e.g.,  textual  summaries,  cnarts, 
graphs,  voice,  large  graphic  displays,  static  slides,  etc.).  A 
navigational  capability  will  oe  needed  to  portray  the  structure 
of  the  entire  Knowledge  resource  and  to  assist  in  the  process  of 
determining  where  particular  pieces  ot  information  relevant  to  a 
request  may  be  founo. 

A - 1 .2.6  Data  Dictionary  / Data  Directory 

An  integral  part  ot  tne  Knowledge  Resource  Center  (see 
A - l . 2 . b above)  and  something  essential  to  effective  data  and 
Knowledge  sharing  in  a computer  networK  is  a data  dictionary  / 
oata  directory  system  which  serves  as  a central  point  ot  aetini- 
tion  and  location  tor  all  the  data  items  which  exist  in  data 
oases  throughout  tne  department.  This  is  also  the  focal  point 
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tor  data  standardization.  It  is  here  that  the  various  user  views 
and  terminology  are  reduced  to  a consistent,  canonical  enterprise 
view  and  standard  vocabulary.  bach  data  management  system  may 
maintain  its  own  dictionary/directory,  but  for  the  network  a cen- 
tralized facility  must  be  established  (1)  to  coordinate  the  indi- 
vidual systems,  (2)  to  provide  tor  semantic  validation  and 
consistency-checking  of  the  various  external  and  internal  schemas 
against  the  conceptual  schema  and  the  conceptual  schema  aqainst 
the  real  world,  (3)  to  provide  a model  tor  data  location  in  a 
distributed  data  base  environment,  and  (4)  to  permit  synonym 
resolution  among  the  external  schemas  in  an  attempt  to  relieve 
the  end-user  from  having  to  employ  standard  terminology.  An 
automated  information  system  will  be  necessary  for  manipulating 
and  accessing  the  dictionary/directory  and  the  question  of  allow- 
ing automatic  additions  and  deletions  will  have  to  be  investi- 
gated. If  the  dictionary/directory  is  maintained  as  an  overhead 
superfluous  function  instead  of  being  automated  and  fed  directly 
from  the  many  data  bases  of  the  Agency,  it  will  rapidly  grow 
out-of-date  and  become  useless.  Alternatively,  non-automation 
may  require  a prohibitive  expenditure  of  human  resources  to  keep 
it  up-to-date.  Little  is  known  today  about  how  to  maintain 
automatically  a dictionary/directory  of  dynamic  data  bases,  and 
research  is  badly  needed  to  define  this  critical  area. 

A- 1 . 2 . 7 Secur ity 

In  the  area  of  security,  the  organization  must  recognize  the 
vital  nature  of  the  conceptual  schema  (in  essence,  the  roadmap  to 
all  the  knowledge  of  the  department)  and  must  take  extraordinary 
measures  to  preserve  its  integrity  and  privacy.  These  considera- 
tions are  also  part  of  the  rationale  tor  having  an  independent 
knowledge  resource  center.  The  conceptual  schema  contains  not 
only  data  in  the  traditional  sense  but  a heavy  proportion  of 
metadata  (or  data  about  this  data).  To  date,  little  research  has 
been  done  concerning  the  security  requirements  for  metadata, 
what  is  needed  is  a secure  information  system,  which  implies  a 
secure  operating  system,  wnicn  implies  a secure  computer.  Lack- 
ing such  an  environment,  the  organization  must  perform  a vulnera- 
bility assessment  and  develop  methods  and  procedures  for  control- 
ling access  to  the  conceptual  scnema  while  helping  to  establish 
policies  on  the  dissemination  of  knowledge  from  the  knowledge 
resource . 

A- 1 . 3 IN TLRNAL  MODbL 

fne  role  of  Data  base  Administrators  (DBA)  undoubtedly  will 
be  filled  by  m-any  people.  In  a physical  environment,  where  there 
are  several  diverse  processing  centers  under  the  control  of  a 
department,  there  may  be  a DBA  for  each  of  these  centers;  or 
there  may  be  a DBA  in  charge  of  each  of  the  data  management  func- 
tional areas.  Tne  organization  may  wish  to  organize  its  DBA's 
under  some  hierarchical  structure  in  which  there  is  a highest 
authority  DBA  to  wnom  all  the  others  must  eventually  report. 
This  person  may  also  be  the  Lnterprise  Administrator,  but  more 
likely  he  or  she  will  be  a key  staff  assistant  to  the  LA.  It 
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must  remain  clear  tnat  tne  domain  of  the  DBA  is  strictly  techni- 
cal. The  DBA  is  responsible  lor  the  performance  o 1 the  indivi- 
dual functional  components  as  well  as  the  technical  details  of 
inter-system  communication  and  Knowledge  sharing.  It  is  up  to 
the  DBA  staff  to  Keep  tracK  of  advances  in  technology  which  can 
be  used  by  the  enterprise  to  enhance  its  data  management 
activity. 

A-1,3.1  Hardware 

fhe  chief  technical  advisor  on  the  hardware  aspects  of  a 
Knowledge  resource  will  be  the  Data  Base  Administrator  who  must 
tracK  the  state-of-the-art  in  hardware  development  tor  data 
management.  Several  existing  activities  warrant  close  monitoring 
and  investigation  by  the  DBA  and  the  staff.  These  areas  include: 
bacK-end  processors  tor  data  management  functions,  centralized 
data  management  machines  for  a network,  more  intelligent  disK 
controllers,  associative  processors,  arrays  of  microprocessors 
for  parallel  specialized  searching,  microprogramming  of  data 
management  functions,  mass  memory  technology,  a methodology  of 
storage  hierarchy  management,  distrioution  of  functions  among 
tightly  linKed  front-end,  middle,  and  back-end  computers,  and  the 
development  of  new  access  methods.  In  addition  to  tracking 
current  activity,  the  DBA  should  perform  and  maintain  a state- 
of-the-art  trend  analysis  and  cost  prediction  analysis  for  the 
hardware  components  which  are  crucial  in  data  management.  The 
analysis  should  span  the  next  5-10  years  and  should  include  a 
methodology  tor  performing  hardware  cost/benetit  analyses.  As 
the  size  and  the  investment  in  the  knowledge  resource  grows, 
decisions  about  migration  to  new  systems  become  increasingly  more 
critical  in  terms  of  dollar  cost  and  the  impact  on  the 
department's  operation.  The  DBA  will  play  a key  role  in  deter- 
mining the  impact,  feasibility,  cost,  and  appropriate  timing  of 
such  moves. 

A - 1 . 1.2  Performance 

Performance  is  probably  the  one  area  where  data  base  adminis- 
trators receive  the  most  complaints  from  users  and  managers 
aiiKe.  mere  is  a great  need  for  tuning  tools  tor  hardware, 
software,  schema  design,  and  query  processing.  In  adaition, 
models  of  significant  performance  variables  are  also  neeaed  to 
allow  hypothetical  tuning  without  affecting  the  actual  running 
system.  Tnese  models  and  tools  must  be  available  for  an  entire 
network  and  its  unique  problems  as  well  as  tor  the  individual 
systems  within  the  network.  Furthermore,  tools  are  neeaed  to 
measure  actual  data  base  usage  and  compare  it  against  original 
design  specifications  to  determine  when  re-structuring  is  war- 
ranted. A dynamic  re-structuring  capability  in  individual  sys- 
tems can  also  be  a significant  performance  factor.  Finally, 
there  is  the  need  to  develop  an  evaluation  procedure  tor  deter- 
mining the  suitability  of  various  access  methods  tor  different 
applicat ions . 
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A- l . i . j Security 

In  the  security  area  there  is  great  need  for  improved  secu- 
rity  techniques  in  all  layers  of  hardware  and  software.  The  DBA 
should  follow  and  support  activities  in  data  encipherment,  user 
authentication,  development  of  secure  operating  systems,  con- 
struction of  automated  security  aids  (such  as  monitors,  auditors, 
alarms,  etc.),  evaluation  of  penetration  techniques,  construction 
of  a security-filter  interface  between  the  data  management 
software  and  the  applications  or  users,  and  finally,  the  develop- 
ment of  a Knowledge-based  tront-end  computer  to  perform  security 
monitoring  and  to  make  decisions  and  draw  inferences  aoout  indi- 
vidual accesses  to  the  information  resource.  At  the  very  least 
the  DBA  must  be  responsible  for  insuring  that  the  data  management 
systems  offer  no  additional  security  holes  or  risks  to  already 
weak  operating  systems. 

A-i.i.4  Integrity 

Several  areas  in  the  category  of  integrity  need  to  be 
enhanced.  Again,  preserving  the  integrity  of  the  data  base  is 
the  responsibility  of  the  DBA.  Work  should  be  done  to  devise  a 
workable  and  agreed-upon  technique  tor  locking  and  for  resolving 
deadlocks  (this  is  especially  important  in  a computer  network). 
Rapid  recovery  from  failure  is  also  a very  real  issue  with  large 
operational  data  bases.  Adequate  audit-trail  capabilities  for 
back-up,  integrity-checking  routines  tor  maintenance,  and  res- 
toration tools  tor  recovery  all  need  to  be  developed.  Finally,  a 
technique  for  automatically  checking  the  semantic  consistency  of 
data  would  be  useful  (e.g.,  field  A must  be  less  than  10000  if 
field  6 is  between  76  and  92). 

A- l . 1 . 5 Input 

The  Data  base  Administrator  is  responsible  for  the  physical 
mapping  of  the  logical  data  base  to  the  physical  storage  devices. 
Tools  are  needed  to  improve  the  efficiency  of  this  process  and  to 
cut  down  on  trial  and  error  data  base  design.  A methodology  is 
needed  for  determining  in  advance  the  expected  size  of  a data 
base  as  well  as  performance  characteristics  to  be  expected. 
Models  are  necessary  to  allow  the  simulation  of  tne  effects  of 
certain  parameter  cnanges  on  the  performance  of  tne  system.  In 
the  area  of  inputting  the  logical  structure  of  the  data  base, 
schema  navigation  tools  are  needed  to  assist  the  DBA  in  perusing 
and  altering  existing  scnemas.  Automated  procedures  for  migrat- 
ing existing  data  bases  to  new  hardware  or  software  are  essen- 
tial. Techniques  are  needed  tor  automatically  generating  schemas 
from  diagrams  or  sample  programs.  Also,  a method  for  keeping 
track  of  multiple  versions  of  a schema  would  assist  in  maintain- 
ing a data  base  whose  structure  changes  dynamically.  Finally, 
there  needs  to  be  developed  a procedure  for  determining  it  the 
internal  schema  as  designed  meets  the  users'  or  applications 
administrators'  requirements. 
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A-l.l.b  Distributed  Data  Bases 

In  a multi-computer  environment  it  may  oe  desired  to  distri- 
bute data  bases  across  several  machines.  The  DBA's  involved  are 
jointly  responsible  for  maintaining  such  an  environment.  They 
will  need  to  support  research  to  develop  techniques  for  easing 
data  migration  or  roll-over  of  applications  from  one  system  to 
anotner;  to  devise  an  effective  scheme  for  keeping  copies  of  a 
data  base  in  synchrony;  to  develop  ways  of  dynamically  allocating 
network  resources  (e.g.,  storage,  communications  facilities,  data 
management  capabilities,  etc.);  to  develop  and  employ  subnetwork 
models  within  a computer  network;  and  to  devise  techniques  for 
solvinq  problems  which  take  on  new  significance  when  distributed 
data  oases  are  Involved  (e.g.,  update,  Integrity,  access  limita- 
tion, locking,  etc.).  In  some  instances  it  may  be  desirable  to 
divide  a large  data  base  into  several  discrete  logical  subsets  in 
order  to  permit  parallel  accessing  Ci.e.,  assigning  parallel  suo- 
tasks  to  individual  systems  in  the  network).  In  this  regard, 
work  needs  to  be  done  to  provide  local  and  global  views  of  a data 
base  to  ennance  performance.  Similarly,  the  division  of  a data 
base  into  discrete  Physical  subsets  can  be  used  to  permit  physi- 
cal parallel  access  such  as  with  an  array  of  microprocessors. 

A-1.4  EXTERNAL  MODEL 

The  external  model  incorporates  both  end-users  and  Applica- 
tions Administrators  CAA).  In  the  model,  these  individuals  are 
envisioned  as  being  under  tne  administrative  control  of  the  vari- 
ous divisions  of  the  applications  areas.  They  may  work  with,  but 
do  not  report  to,  tne  Data  Base  Administrator  or  the  Enterprise 
Administrator.  They  are  app 1 icat ions -or i ented  with  specific 
tasks  to  oe  accomplished  tor  which  the  data  resource  is  only  a 
tool.  Tne  job  of  the  AA  is  to  insure  that  the  end-users  can 
obtain  tne  knowledge  which  they  need  to  perform  their  tasks,  and 
tnat  they  can  get  it  fairly  easily.  In  this  position  the  AA  is 
largely  concerned  with  the  user  interfaces:  their  variety, 
appropriateness,  and  power.  He  is  also  concerned  with  the  pro- 
duction of  knowledge  by  the  sub-groups  of  the  department  from  the 
knowledge  resource.  In  order  to  support  this  position,  a large 
number  of  tools  and  improvements  to  existing  systems  need  to  be 
deve loped. 


A-1.4. l Data  Base  Access 

There  are  many  possible  user  Interfaces  for  accessing  data 
(see  Section  6.1).  Each  differs  in  the  amount  and  kind  ot 
knowledge  or  skills  required  for  the  user  to  become  proficient  in 
tneir  use,  in  the  degree  of  difficulty  and  flexibility  in  making 
the  request,  in  the  amount  ot  processing  required  of  the  machine, 
in  the  form  ot  presentation  of  the  response,  and  in  the  informa- 
tion bandwidth  ot  the  interface.  These  interfaces  embody  a spec- 
trum ot  capaoi l i t ies , and  research  is  needed  in  each  area  to 
improve  the  capabilities  as  necessary.  In  some  instances  new 
technology  will  pe  required;  in  others,  orlv  a new  application  of 
old  technology  is  needed.  In  any  case,  research  needs  to  be  done 
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on  how  to  allow  the  user  to  make  an  easy  transition  from  one 
interface  to  another. 

A-l.4.2  Data  Presentation 

Like  the  Enterprise  Administrator,  the  end-users  need  to 
increase  the  effectiveness  of  data  presentation,  while  their 
data  is  different,  the  methods  of  presentation  are  similar. 
Technology  such  as  super  imposing  images  over  pictures  Ce.g., 
slides  or  television)  should  be  investigated  to  reduce  the  volume 
of  data  generally  associated  with  computer-generated  graphics. 
Human  factors  concerning  the  relative  ease  of  interpretation  of 
various  forms  of  presentation  such  as  graphs,  charts,  tables,  or 
text  need  to  be  studied.  An  automatic  exception-reporting  capa- 
bility in  which  an  alerter  is  triggered  when  certain  user- 
specified  conditions  occur  in  a data  base  can  have  great  implica- 
tions. Finally,  methods  of  summarizing  data  from  numbers, 
graphs,  or  text  and  presenting  the  summaries  in  the  most  intelli- 
gible form  need  to  be  investigated.  Consideration  of  the  infor- 
mation bandwidth  capability  of  each  presentation  form  will  take 
on  increasing  importance  as  users  tend  more  and  more  to  move  away 
from  bulk  computer  print-outs. 

A-i.4.3  Navigation 

End-users  and  applications  administrators  have  need  for  a 
navigational  facility  which  will  allow  them  to  browse  through  a 
data  base  with  an  unknown  schema.  The  data  base  must  be  capable 
of  instructing  the  user  as  to  its  structure  and  use.  Techniques 
are  needed  for  determining  the  "optimal"  path  to  a data  item 
(shortest,  fastest,  informationally  richest).  Also  needed  are 
methods  for  generating  automatically  the  necessary  access  code. 
Pre-retrieval  query  analysis  (complexity  or  cost  estimation)  and 
query  simulation  can  help  conserve  machine  as  well  as  human 
resources.  In  general,  the  techniques  of  computer-aided  instruc- 
tion should  be  applied  to  the  task  of  informing  the  user  how  best 
to  use  the  resources  available. 

A-l.4.4  Data  Validation 

Initial  validation  of  input  data  must  occur  before  the  data 
is  entered  into  the  data  base.  Methods  of  automatic  error  detec- 
tion and  correction  (perhaps  employing  semantics  and  context) 
which  filter  data  before  it  is  entered  into  the  data  base  need  to 
be  developed.  Once  tne  data  has  been  entered,  however,  further 
validation  should  be  performed  as  ah  integrity  check.  Methods  to 
do  this  are  badly  needed.  A scheme  also  needs  to  be  developed  to 
validate  derived  data  (or  to  validate  the  algorithms  used  in 
deriving  the  data).  Validation  techniques  are  needed  for  testing 
tne.  consistency  of  the  conceptual,  internal,  and  external  sche- 
mas. Finally,  some  method  of  associating  a validity  value  with 
each  data  element  (e.g.,  0-100%)  and  with  data  bases  in  general 
needs  to  oe  developed  so  that  meaningful  validities  can  be 
assigned  to  information  derived  from  multiple  sources.  In  addi- 
tion to  the  numerical  values  assigned  to  the  validities  it  is 
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often  desirable  (and  sometimes  essential)  to  preserve  a reference 
to  the  individual  responsible  for  assigning  the  current  validity 
values . 

On  output,  certain  probabilistic  filters  are  needed  to  filter 
out  data  having  a validity  below  a given  threshold.  The  capabil- 
ity to  check  context  integrity  before  releasing  information  is 
also  desirable  as  is  the  ability  to  validate  queries  before  they 
are  executed, 

A-l.4.5  Data  Entry 

Efficient  techniques  for  handling  the  entry  of  large  volumes 
of  data  are  sorely  needed,  ' Rapid  file  management  techniques  can 
be  used  to  capture  large  volumes  of  "live"  data  and  to  hold  it 
for  later  processing,  but  more  effective  methods  for  passing  this 
data  on  to  subsequent  processes  are  needed.  Currently,  arbitrary 
data  entry  user  interfaces  and  data  managers  are  not  designed  to 
be  transportable  and  are,  in  fact,  bound  in  specific  subsets. 
The  result  is  that  there  is  a multiplicity  of  data  entry  pack- 
ages, all  serving  essentially  the  same  function.  This  is  further 
complicated  by  the  fact  that  once  the  data  is  stored  via  one  data 
manager  it  is  not  easily  transferred  to  some  other  data  manage- 
ment system  for  further  processing.  Some  coordination  of  these 
efforts  is  required  in  order  to  effect  data  sharing  among  all 
levels  of  the  Functional  View.  From  the  end-user's  point  of 
view,  standard  data  entry  protocols  for  all  processes  in  the 
enterprise  would  reduce  training  requirements  and  increase  human 
efficiency.  Effective  knowledge  representation  can  also  assist 
in  this  process  by  allowing  better  first-line  editing. 

A - 1 .4.6  Correlation  and  Inferencing 

The  end-users  want  to  be  able  to  correlate  data  and  knowledge 
from  a variety  of  Places  in  the  knowledge  resource.  The  DBA's 
have  been  assigned  the  task  of  providing  the  capability  to  access 
different  data  bases,  but  additional  tools  are  needed  to  assist 
the  user  in  drawing  inferences  and  conclusions  from  multiple  data 
sources,  i.e.,  in  abstracting  knowledge.  Tools  are  needed  to 
model  the  real  world,  to  develop  and  test  hypotheses  about  the 
real  world  based  on  the  data  available,  and  to  project  the  impli- 
cations of  a hypothesis  about  the  real  world  through  some  simula- 
tion mechanism.  Current  work  in  Question-Answering  systems  and 
automatic  inferencing  needs  improvement  in  the  following  areas: 
question  presentation,  interactive  question  enhancement,  the 
applicatloh  of  probabilistic  rules,  fuzzy  logic,  basic  inferenc- 
ing techniques,  answer  presentation,  proof  demonstration,  and 
inductive  inferencing  of  rules  from  sample  data  (with  applica- 
tions to  trend  analysis).  One  further  very  interesting  problem 
is  the  use  of  time-dependencies  on  queries  in  order  to  keep 
straight  the  accession  of  archival  data  bases. 

In  this  Appendix  we  have  tried  to  identify  many  of  the  techn- 
ical problems  which  an  organization  can  expect  to  face  in  estab- 
lishing a a knowledge  resource.  Several  research  topics  were 
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listed  in  conjunction  with  the  problem  areas  associated  with  each 
of  the  three  models  ot  information.  To  be  complete,  a knowledge 
resource  research  program  must  at  least  consider  these  areas  and 
determine  where  solutions  can  be  expected  to  appear  on  their  own 
and  where  the  department  must  actively  support  research  efforts 
to  increase  the  chances  of  their  success  in  a relevant  timespan. 
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UNIX  PROTOTYPE 


A-2.1.  INTRODUCTION 

Some  preliminary  work  has  begun  in  various  government  organi- 
zations in  order  to  test  the  feasibility  of  the  logical  system 
design  described  in  Section  8.  The  work  is  being  done  on  the 
UNIX  operating  system  [35]  with  Digital  Equipment  Corporation 
PDP-11  computers.  It  should  be  emphasized  at  the  outset  that  the 
combination  of  UNIX  and  PDP  ll's  was  selected  only  as  a prototype 
for  initial  testing  of  the  logical  system  design.  No  conclusions 
nave  been  reached  as  yet  concerning  the  practicality  of  employing 
UNIX  in  a production-model  implementation?  indeed,  alternative 
hardware  cont i gurat ions  such  as  multiple  PDP-ll's  or  some 
larger-scale  computers  must  be  considered.  Hundreds  of  UNIX 
installations  presently  exist  all  over  the  country.  They  are 
found  in  universities,  government  departments,  and  in  private 
organizations.  In  addition,  UNIX  has  been  selected  to  form  the 
basis  of  DARPA's  Intelligent  Terminal  program,  and  considerable 
techno  logical  fallout  is  expected  from  that  effort. 

A - 2 . 2 FACTUAL  KNOWLEDGE  SUBSYSTEM 

A relational  data  base  management  system  called  INGRES  is 
available  from  the  University  of  California  at  Berkeley  and  it 
has  oeen  installed  on  several  UNIX  systems.  The  product  is 
experimental,  but  one  which  is  recognized  as  a good  implementa- 
tion of  relational  principles.  Test  and  evaluation  procedures 
have  begun  in  several  organizat ions  in  order  to  determine  the 
efficiency  and  app l icaoi 1 ity  of  INGRES  for  some  live  situations, 

ELS  Systems  Engineering,  Inc.  of  Cleveland,  Ohio  offers  a 
file  management  system  called  Product  3 to  the  UNIX  environment. 
The  software  is  available  for  purchase. 

UNIX  has  its  own  hierarchically  structured  file  system  whicn 
is  recognized  as  a remarkable  implementation  among  minicomputer 
operating  systems. 

A-2.3  JUDGMENT  SUPPORT  SUBSYSTEM 

The  System  Development  Corporation  of  Santa  Monica,  Califor- 
nia has  begun  to  implement  a generalized  natural  language  subset 
interface  to  INGRES  (see  Section  A-2.2).  This  work  is  expected 
to  oe  completed  in  2nd  Quarter  FY-78, 

Research  efforts  on  a navigational  interface  have  begun  to 
report  some  of  their  results  in  tne  literature.  An  experimental 
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tool  for  navigating  CODASYL  scnemas  has  been  developed  which 
displays  a picture  ot  the  structure  of  any  CUDASYL  data  base  by 
using  computer-generated  graphics. 

The  specifications  for  a forms  interface  have  been  compiled 
by  tne  CODASYL  End  user  Facilities  Committee,  but  no  implementa- 
tions of  a generalized  forms  interface  are  currently  available, 

Uuery  languages,  relational,  and  programmatic  interfaces  are 
available  with  the  three  data  managers  listed  in  Section  A-2,2. 
Some  future  work;  to  arrive  at  a standard  for  each  category  will 
oe  necessary.  Efforts  which  will  lead  to  graphical,  menu,  dialo- 
gue, and  transaction  processors  appear  to  be  underway. 

Finally,  a superb  text-editor  from  the  Rand  Corporation  is 
available  for  UNIX.  This  editor  appears  to  have  great  potential 
for  a variety  of  applications. 

A-2.4  PROCEDURAL  KNOWLEDGE  SUBSYSTEM 

There  is  a primitive  knowledge-based  system  available  on  UNIX 
wnich  is  called  RITA  (see  Section  5.1.6).  RITA  has  been 
developed  by  the  Rand  Corporation  as  part  of  DARPA's  Intelligent 
Terminal  program.  RITA  is  presently  installed  on  several  govern- 
ment computer  systems,  and  experiments  are  gettina  underway  to 
test  the  implementation  and  possible  applications. 


A-2.5  TRANSLATION  AND  CONTROL  SUBSYSTEM 

The  Translation  and  Control  Subsystem  appears  to  require  con- 
siderably more  research  than  the  other  three  areas.  Several 
canonical  representations  and  translation  mapping  mechanisms  are 
under  investigation  at  numerous  research  institutions  throughout 
the  country.  Martin  Marietta  Corporation  in  Denver,  Colorado  has 
proposed  the  use  ot  the  DIAM  representation  developed  by  Dr. 
Michael  Senko  at  IBM  (38J.  The  University  of  Maryland  in  College 
Parx,  Maryland  and  Set-Theoretic  Information  Systems  Corporation 
in  Ann  Arbor,  Michigan  are  both  investigating  Extended  Set  Theory 
[ i 9 J as  a possible  canonical  representation.  Finally,  Dr.  Peter 
Rin-Shan  Chen  at  MIT  140J  has  proposed  an  Entity-Relationship 
theory  whicn  appears  to  hold  great  promise.  None  of  this  work  is 
currently  involved  with  UNIX.  In  fact,  it  may  not  be  prudent  at 
this  time  to  constrain  the  research  by  forcing  it  to  tit  the  UNIX 
mold.  Rather,  perhaps  it  might  be  best  to  encourage  the  develop- 
ment of  the  theory  first  and  then  later  move  to  a UNIX  prototype 
(as  has  happened  already  in  the  data  management  area).  Similar 
remarks  apply  to  the  distributed  data  base,  distributed 
diet  ionary/di  rectory , and  data  location  research. 

initial  implementations  of  user  interfaces  are  intended  to 
have  direct  connections  to  tne  appropriate  data  managers.  As  the 
elements  ot  the  Translation  and  Control  Subsystem  are  developed 
they  will  need  to  be  phased  into  the  total  system.  The  user 
interlaces  must  oe  designed  so  that  a clean  break  from  the  data 
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managers  and  connections  to  the  intermediate  subsystems  are  pos- 
sible. The  success  of  the  individual  user  interfaces  ano  data 
managers  should  not  depend  on  the  success  of  the  development  of 
the  Translation  and  Control  Subsystem  since  useful  packages  can 
oe  developed  with  direct  connections.  The  success  of  a total 
distributed  knowledge  resource  is,  however,  dependent  upon  the 
ultimate  success  of  the  canonical  representation  and  mapping 
modules  since  this  is  to  be  the  common  form  tor  representing 
information  among  distributed  systems. 

Numerous  other  software  products  are  now  available  or  are 
under  development  for  UNIX.  These  include: 

* Programmers'  Workbench  - a system  for  software  development 

* VUTRAX  - a voice  synthesizer  for  vocal  output 

* Security  Kernel  - to  enhance  system  security 

* Graphics  - a system  employing  raster-scan  video  technology 

* Network  Control  Program  - for  connection  to  ARPAnet 

* Message  subsystem  - for  user  communication 

* Project  Management  Subsystem  - to  support  project  management 

* Document  Preparation  Package  - for  word-processing 

* LISP,  APL,  t'C  L , FORTRAN  IV  PLUS  - programming  languages 

These  tools,  together  with  the  knowledge  resource  software 
described  in  the  preceding  sections,  hold  great  promise  for 
developing  a very  strong  user-oriented  system,  however,  it  is 
necessary  to  repeat  the  earlier  caveat  that  what  is  being  done  is 
initial  research  on  the  components  of  a knowledge  resource.  In 
this  environment,  UNIX  will  form  the  basis  for  an  initial  proto- 
type. It  is  not  suggested  that  this  work  will  constitute  the 
final  solution. 


